[llvm] [SelectionDAG] Handle more opcodes in canCreateUndefOrPoison (PR #84921)

[Björn Pettersson via llvm-commits]

================
@@ -260,15 +260,17 @@ define i32 @ctlz_lshr_i32(i32 signext %a) {
 ; RV64I-NEXT:    .cfi_def_cfa_offset 16
 ; RV64I-NEXT:    sd ra, 8(sp) # 8-byte Folded Spill
 ; RV64I-NEXT:    .cfi_offset ra, -8
-; RV64I-NEXT:    srliw a1, a0, 1
+; RV64I-NEXT:    srli a1, a0, 1
 ; RV64I-NEXT:    or a0, a0, a1
-; RV64I-NEXT:    srliw a1, a0, 2
+; RV64I-NEXT:    srli a1, a0, 2
 ; RV64I-NEXT:    or a0, a0, a1
-; RV64I-NEXT:    srliw a1, a0, 4
+; RV64I-NEXT:    srli a1, a0, 4
 ; RV64I-NEXT:    or a0, a0, a1
-; RV64I-NEXT:    srliw a1, a0, 8
+; RV64I-NEXT:    slli a1, a0, 33
+; RV64I-NEXT:    srli a1, a1, 41
 ; RV64I-NEXT:    or a0, a0, a1
-; RV64I-NEXT:    srliw a1, a0, 16
+; RV64I-NEXT:    slli a1, a0, 33
+; RV64I-NEXT:    srli a1, a1, 49
----------------
bjope wrote:

(Ok, I see, so this part with SRA/SRL has already been attempted earlier. )

One thing that changes is that we get a FREEZE before the AssertZext. So the theory is that the FREEZE is blocking the computeKnownBits analysis (either directly or indirectly due to recursion limit), and causing the regression here.

And if we deal with the AssertSext/AssertZext like we do with "poison generating flags", then we would just fold (freeze(AssertZext(x))) into (freeze(x)). But that would also lose the information given by the assert node.

It had been nice if we could see AssertSext/AssertZext as blocking poison (or just propagating poison). Kind of like a FREEZE with a hint that the result value is in a given range. But then we for example need to do something about the AssertSext inserted by PromoteIntRes_FP_TO_XINT (or we reintroduce the problem from https://github.com/llvm/llvm-project/issues/66603).

Or maybe we can fold (freeze(assertZext(CopyFromReg))) into just (assertZext(CopyFromReg)) assuming that it is OK when the assert node only is used as attribute on an external value.


https://github.com/llvm/llvm-project/pull/84921