[PATCH] D66232: [InstCombine] Try to reuse constant from select in leading comparison
Dávid Bolvanský via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 22 09:55:31 PDT 2019
xbolva00 added a comment.
I like idea here and patch seems generally fine.
@nikic, @dmgreen, @spatel are probably interested to check this too.
================
Comment at: llvm/test/Transforms/InstCombine/unrecognized_three-way-comparison.ll:92-106
define i32 @compare_against_two(i32 %x) {
; CHECK-LABEL: @compare_against_two(
; CHECK-NEXT: entry:
-; CHECK-NEXT: [[TMP0:%.*]] = icmp sgt i32 [[X:%.*]], 2
-; CHECK-NEXT: br i1 [[TMP0]], label [[CALLFOO:%.*]], label [[EXIT:%.*]]
+; CHECK-NEXT: [[CMP1:%.*]] = icmp eq i32 [[X:%.*]], 2
+; CHECK-NEXT: [[CMP2_INV:%.*]] = icmp sgt i32 [[X]], 1
+; CHECK-NEXT: [[SELECT1:%.*]] = select i1 [[CMP2_INV]], i32 1, i32 -1
+; CHECK-NEXT: [[SELECT2:%.*]] = select i1 [[CMP1]], i32 0, i32 [[SELECT1]]
----------------
lebedev.ri wrote:
> xbolva00 wrote:
> > lebedev.ri wrote:
> > > This is clearly a regression.
> > > I suppose it means this fold happens before some other fold that used to happen,
> > > and that fold does not know how to deal with the new pattern.
> > > I'd prefer to look into this afterwards.
> > No status update here? Or did you find what is broken?
> >
> > Patch looks fine I think, but this worries me - we may realize later that the root cause of regression is possibly nontrivial thing which could lead us to rever this one. (and wasted time).
> Added some tests in rL369667.
> Whatever handles this is "simply" ignorant about commutativity.
Ok, thanks for info.
(Not a patch blocker)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D66232/new/
https://reviews.llvm.org/D66232
More information about the llvm-commits
mailing list