[llvm] [DAGCombiner] Freeze maybe poison operands when folding select to logic (PR #84924)
Björn Pettersson via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 26 08:17:12 PDT 2024
================
@@ -295,22 +295,28 @@ define float @select_icmp_sle(i32 %x, i32 %y, float %a, float %b) {
; Test peephole optimizations for select.
define zeroext i1 @select_opt1(i1 zeroext %c, i1 zeroext %a) {
; CHECK-LABEL: select_opt1
-; CHECK: orr {{w[0-9]+}}, w0, w1
+; SISEL: orr [[REG:w[0-9]+]], w0, w1
+; SISEL: and w0, [[REG]], #0x1
+; FISEL: orr {{w[0-9]+}}, w0, w1
%1 = select i1 %c, i1 true, i1 %a
ret i1 %1
}
define zeroext i1 @select_opt2(i1 zeroext %c, i1 zeroext %a) {
; CHECK-LABEL: select_opt2
-; CHECK: eor [[REG:w[0-9]+]], w0, #0x1
-; CHECK: orr {{w[0-9]+}}, [[REG]], w1
+; SISEL: orn [[REG:w[0-9]+]], w1, w0
+; SISEL: and w0, [[REG]], #0x1
+; FISEL: eor [[REG:w[0-9]+]], w0, #0x1
+; FISEL: orr {{w[0-9]+}}, [[REG]], w1
%1 = select i1 %c, i1 %a, i1 true
ret i1 %1
}
define zeroext i1 @select_opt3(i1 zeroext %c, i1 zeroext %a) {
; CHECK-LABEL: select_opt3
-; CHECK: bic {{w[0-9]+}}, w1, w0
----------------
bjope wrote:
Well, one idea is that we get rid of the known, IMHO, misuse of AssertSext/AssertZext in DAGTypeLegalizer::PromoteIntRes_FP_TO_XINT. And then try to check all other places that create AssertSext/AssertZext nodes to see if they are violating the desciption of those ISD nodes (i.e. that they "record if a register contains a value that has already been zero or sign extended"). In the PromoteIntRes_FP_TO_XINT those nodes are used to indicate that it is the result is poison if the input violates the assert. But the desciption of the assert nodes just say that the result is poison if the input is poison.
This probably result in various regressions, so maybe not acceptable.
Another idea would be to add some kind of boolean parameter to AssertSext/AssertZext that makes it possible to indicate that the assert node only propagates posion or if it can create poison. This flag could then be used in situations like PromoteIntRes_FP_TO_XINT.
OTOH, considering that https://github.com/llvm/llvm-project/issues/66603 still is open. Maybe the revert in https://github.com/llvm/llvm-project/commit/8505c3b15bfc535ff6624e71add4082680745187 wasn't needed after all?
https://github.com/llvm/llvm-project/pull/84924
More information about the llvm-commits
mailing list