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

[Matteo Bruni]

On Wed, Jan 19, 2022 at 1:42 PM Giovanni Mascellani
<gmascellani at codeweavers.com> wrote:
>
> Hi,
>
> Il 19/01/22 13:10, Matteo Bruni ha scritto:
> > 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.
>
> I am not completely sure of what you mean here. You say that you fear
> that if we have "(x + y) + z" with x, y and z constants, native compiler
> could transform this to "x + (y + z)" before doing constant folding?

My example would be something like:

result = x + 4 + 2;

which the compiler then transforms into:

result = x + 6;

by means of constant folding. Assuming x is float, technically those
two might not be the same because of rounding errors (although
probably there is no danger with these particular values).

But that's moot for d3dcompiler. My question is whether any other
vkd3d-shader user would care. My guess is probably not, and even in
that case we can wait to add the feature until said user comes up.