https://bugs.kde.org/show_bug.cgi?id=352364
--- Comment #4 from Julian Seward <jsew...@acm.org> --- On contemplation, it is probably easiest to fix this in ir_opt.c by doing an IR-to-IR transformation pass that, following the example in comment 3, transforms CmpEQ32( select-bit-1-of( CmpORD64U(x,y) ), 0x0 ) to CmpNE64(x,y) where "select-bit-1-of" incorporates all the size-changing and masking gunk (64to8, then 8Uto32, then And32 with 2, then Xor32 with 2). We could be cleverer about the size-changing and masking bits, for example declaring CmpORD64U to produce a I32 typed result, since matching IR patterns is hard work and it's easy to miss cases. With that change the example simplifies to t54 = CmpORD64U(t48,0xCD:I64) if (CmpEQ32(Xor32(And32(t54,0x2:I32),0x2:I32),0x0:I32)) ... and if we get rid of the Xor32 and instead compare the extracted value with 2: t54 = CmpORD64U(t48,0xCD:I64) if (CmpEQ32( And32(t54,0x2:I32), 0x2:I32)) ... That would make the matching problem easier. Furthermore if we normalise And32 and CmpEQ32 nodes so that if just one of the args is a constant than it is on the right, then there are no L-vs-R structural variants to consider. There is a bunch of infrastructure in ir_opt.c, starting at line 5953, for "MSVC specific transformation hacks", that would form a useful starting point. -- You are receiving this mail because: You are watching all bug changes.
