[PATCH vkd3d] vkd3d-shader/hlsl: Handle constant value operations on a different file.

[Matteo Bruni]

On Tue, Jan 4, 2022 at 5:59 PM Francisco Casas <fcasas at codeweavers.com> wrote:
>
> January 4, 2022 11:36 AM, "Giovanni Mascellani" <gmascellani at codeweavers.com> wrote:
>
> > Hi,
> >
> > On 03/01/22 15:57, Francisco Casas wrote:
> >
> >> On constant folding, first switch on the op type, handling each
> >> operation using a function defined on hlsl_constant_ops.c.
> >
> > Creating a new file makes sense to me, but while you're doing it it also makes sense to copy there
> > the whole implementation of fold_constants(), doesn't it? It logically related to
> > hlsl_constant_ops.c, and it also spares you adding a lot of functions to the header file (also, if
> > you do that you probably have only one function to add to the header, fold_constants() itself, and
> > you can put it in hlsl.h instead of creating a new file).
> >
> That sounds like a very good idea to me!
>
> > While I don't have any specific objection against it, is there a particular reason for inverting
> > the switch on the type and on the operation?
> >
>
> Zebediah mentioned that in the future we may want to add operations that aren't typed.
> Also, I think that splitting the problem op-wise allows for a better organization since there
> are fairly more ops than types.

I agree, it looks much better to me this way.

> >> Each of these operations switches on the data type, if needed.
> >
> > As I just said on the other thread (where I replied before noticing this one), watch out for
> > undefined behavior that some operations entail.
> >
>
> Noted. The only problem with (+), (*), and (-), I can think of is signed integer overflow.
> I am not sure yet if implicit castings in C may result in undefined behaviors, I must check.

Another one that potentially needs some care is folding float
expressions. E.g. even transforming a "(x + a) + b" into "x + (a + b)"
(with x float, a and b constants) can technically affect the final
result, depending on the specific values.
We need to replicate MS's compiler in this regard, or at least support
compatible behavior as one of the options. I've been looking into this
a bit and it appears that the native compiler always allows constant
folding transformations, regardless of the presence of the precise
keyword or the D3DCOMPILE_IEEE_STRICTNESS flag to D3DCompile(). Other
transformations / optimizations are affected but I guess we'll think
about those when we get there.

So, as far as constant folding is concerned, always optimizing float
constants should be okay. Or we could have our own compilation flag to
control that, in case we feel that behavior might be useful to some
non-Wine user.