On 8/13/21 9:03 AM, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni mbruni@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?