[PATCH vkd3d 5/6] vkd3d-shader/hlsl: Introduce specialized helpers for arithmetic operations.

[Matteo Bruni]

On Fri, Oct 15, 2021 at 4:54 AM Zebediah Figura <zfigura at codeweavers.com> wrote:
>
> On 10/14/21 12:52 PM, Giovanni Mascellani wrote:
> > Hi,
> >
> > Il 14/10/21 18:32, Zebediah Figura ha scritto:
> >> Yeah, but the ternary operator is a special case. I don't think it
> >> should result in an HLSL_IR_EXPR. Probably we should synthesize a
> >> temporary variable, store to it inside of a conditional, and load from it.
> >
> > Why? I don't know in SM1, but at least in SM4 we have a nice opcode
> > (MOVC) that does just what the ternary operator needs to do, in a way
> > that is probably more efficient (or at least not less efficient) than
> > doing an actual branch. Also, I have a few other patches in my queue
> > that use MOVC for other things (like implementing casts from bool), so
> > I'd like to have it in the IR (not really related to this patch, though).
>
> Well, the usual answer, which is that keeping the scope of the IR low
> makes it easier to work with.
>
> Maybe there's an argument for having a ternary/movc in the IR, but even
> if there is, I'm not sure we really want to make add_expr() more complex
> just for that. Are there any other expressions that (might) take
> operands of non-uniform types?

I agree with all of this, but let me go one step further. In general
the (high-level) IR should express the program using the most basic
elements, then the compiler will figure out how to best map the
program to the output bytecode. For the ternary operator, ideally we
generate an IF in the compiler frontend (e.g. while parsing), then
during instruction selection we notice that we can use MOVC to
implement that particular IF so we do that. Or we lower suitable IFs
to MOVC in a separate pass if it becomes too complicated (but that
would make the most sense as a lower level-IR transformation).

That said, we can certainly compromise and take a more practical route
where it makes sense. The ternary operator doesn't feel like one such
case though, mainly because there is a good chance it would complicate
the rest of the compiler. For example, if some uses of the ternary
operator can't be mapped to MOVC, we potentially need to handle the
ternary op expression in all the passes that care about branches. Or
lower them to regular branches anyway.

I guess this might seem at odds with e.g. my previous suggestion to
lower matrix multiplication directly to a bunch of DP4s or MADs, but
those are pretty regular operations by comparison.