[PATCH vkd3d v3 2/5] vkd3d-shader/hlsl: Rename hlsl_ir_expr_op members.

[Matteo Bruni]

On Fri, Aug 13, 2021 at 6:00 PM Zebediah Figura (she/her)
<zfigura at codeweavers.com> wrote:
>
> On 8/13/21 9:03 AM, Matteo Bruni wrote:
> > Signed-off-by: Matteo Bruni <mbruni at codeweavers.com>
> > ---
> > For reference: originally the plan was for HLSL_IR_EXPR to only cover
> > "mathematical" expressions, or more specifically, pure expressions
> > that could be transformed and moved around (e.g. hoisted out of a
> > loop) without any problem. In that world statements that don't fall
> > under that banner, like texture sampling instructions, would not be
> > expressions.
> >
> > My original setup was inspired by the Mesa GLSL frontend (at the
> > time). It looks like NIR also followed along the same line, with what
> > they call ALU instructions covering our expressions and intrinsic
> > instructions basically matching everything that isn't an ALU
> > instruction or a jump (or SSA stuff).
> >
> > Now, that concept doesn't necessarily need to be preserved in the same
> > form. We probably still need some way to separate "pure" expressions
> > from the rest though. What's your idea in this regard?
>
> I'm not aware of restrictions that fall on sample/load instructions that
> don't apply to pure mathematical expressions. What restrictions are you
> aware of?

Basically, you can't necessarily pull those instructions out of loops
or conditionals, duplicate them when flattening conditionals, CSE them
out etc. Usually those are problematic only when there are also
out-of-pipeline stores (UAVs, shared memory) in the same shader.
See https://people.freedesktop.org/~cwabbott0/nir-docs/instructions.html#intrinsic-instructions
for an overview from the NIR perspective. Confusingly, NIR intrinsic
instructions are not the same thing as HLSL intrinsic functions
(https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-intrinsic-functions)
as the latter are simply functions predefined in HLSL, which would map
to one or more NIR instructions, ALU or otherwise.

Now, maybe we don't need to make any of those "sensitive"
transformations and we avoid the entire issue altogether, but it seems
reasonable to be defensive and provide some way in the IR or the
compiler to distinguish those instructions from the "safe" ones.