On Fri, Oct 15, 2021 at 4:54 AM Zebediah Figura zfigura@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.