[PATCH] D19550: [InstCombine] Determine the result of a select based on a dominating condition.

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 26 18:33:56 PDT 2016


reames added a subscriber: reames.
reames requested changes to this revision.
reames added a reviewer: reames.
reames added a comment.
This revision now requires changes to proceed.

Mostly minor comments, once addressed should be ready to go in.


================
Comment at: lib/Analysis/ValueTracking.cpp:3970
@@ +3969,3 @@
+  // Types must match.
+  if (LHS->getType() != RHS->getType())
+    return None;
----------------
I'm confused by this bit.  How do we get here?  Do we have a select with a non-i1 condition?  If so, maybe the check should be in the caller and we should assert both are i1s?

================
Comment at: test/Transforms/InstCombine/pr21210.ll:34
@@ -33,3 +33,3 @@
 bb:
   %cond = select i1 %cmp, i32 %len, i32 8
   %cmp11 = icmp eq i32 %cond, 8
----------------
Add a check that shows this select disappears.

================
Comment at: test/Transforms/InstCombine/pr21210.ll:44
@@ -44,1 +43,3 @@
+; This seems perfectly fine to me?
+; CHECK: phi i32 [ %len, %bb ], [ undef, %b0 ], [ %0, %entry ]
   %1 = phi i32 [ %cond, %bb ], [ undef, %b0 ], [ %0, %entry ]
----------------
Gerolf wrote:
> cond can be different from len, so you cannot replace it.
> bb-> bb1 vs entry -> b1.
> 
> I think this test covers self-build issues I had ran into when I missed some cases in the  icmp->select->icmp optimization which removes the select in some narrow cases. 
I believe the optimization as posted is correct.  Geroff, were you trying to say it wasn't?  If so, I didn't understand your point.  Could you explain again?


http://reviews.llvm.org/D19550





More information about the llvm-commits mailing list