[PATCH] D154791: [InstCombine] Transform bitwise (A >> C - 1, zext(icmp)) -> zext (bitwise(A < 0, icmp)) fold.
Nikita Popov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 24 03:16:07 PDT 2023
nikic added inline comments.
================
Comment at: llvm/test/Transforms/InstCombine/and-or-icmps.ll:2947
+; CHECK-NEXT: [[TMP2:%.*]] = or i1 [[TMP1]], [[A]]
+; CHECK-NEXT: [[D:%.*]] = zext i1 [[TMP2]] to i32
; CHECK-NEXT: call void @use32(i32 [[B]])
----------------
Based on this we should have m_OneUse on the zext(icmp) as well.
================
Comment at: llvm/test/Transforms/InstCombine/and-or-icmps.ll:2912
+; CHECK-NEXT: [[TMP2:%.*]] = or i1 [[TMP1]], [[A]]
+; CHECK-NEXT: [[D:%.*]] = zext i1 [[TMP2]] to i32
; CHECK-NEXT: call void @use32(i32 [[C]])
----------------
XChy wrote:
> nikic wrote:
> > Creating more instructions here. You should probably always require one-use on the lshr rather than one-use on one of the operands.
> If replacing `icmp eq 100` with other icmp that can be optimized along with `icmp slt 0`, there will be a better IR, except just one extra instruction. Is there some principles that determine whether a one-use guard is necessary or whether a fold is too agressive/conservative? Maybe I can apply them to similar situation in future contributions.
For multi-use we want to avoid instruction increase in the worst case.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154791/new/
https://reviews.llvm.org/D154791
More information about the llvm-commits
mailing list