On 12/17/21 14:40, Giovanni Mascellani wrote:
Hi,
On 17/12/21 19:07, Zebediah Figura (she/her) wrote:
Should we lower these at parse time instead?
Same for LE -> GE.
Don't know. I have to say that I was genuinely surprised that we allowed so much redundancy in the IR, but certainly it won't be me the one who complains about having an expressive IR. So, given that it had already been accepted, I didn't protest.
Well, that code is old, and a lot of the old code doesn't really reflect current preferred design principles.
My feeling is that when your compiler isn't able to handle most trivial arithmetic operators it is a bit early to enter fine discussions about how to best trim the IR so that optimization phases that do not exist yet might be a little bit better or not.
I don't think it's really about optimization in this case. Rather, if we just do something as simple as
- $$ = add_binary_comparison_expr_merge(ctx, $1, $3, HLSL_OP2_GREATER, @2); + $$ = add_binary_comparison_expr_merge(ctx, $3, $1, HLSL_OP2_LESS, @2);
then this patch suddenly doesn't become necessary anymore.