[PATCH] D154791: [InstCombine] Transform bitwise (A >> C - 1, zext(icmp)) -> zext (bitwise(A < 0, icmp)) fold.

[Nikita Popov via Phabricator via llvm-commits]

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