[PATCH] D20143: New pass: guard widening
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Tue May 10 18:19:07 PDT 2016
reames added a comment.
A few initial comments mostly looking at the test cases. I'll take a look at the actual code separately.
My meta concern here is that I think you're trying to be way too aggressive here. "One pass to rule them all" is not generally a good approach. I suspect that smaller changes to InstCombine, EarlyCSE, GVN, and LICM would end up covering most of the interesting cases. Even if we decide to go with a single check widening pass, I'd prefer to see it start dead simple and evolve.
================
Comment at: test/Transforms/GuardWidening/basic.ll:26
@@ +25,3 @@
+; CHECK: call void (i1, ...) @llvm.experimental.guard(i1 %wide.chk) [ "deopt"() ]
+; CHECK: br i1 undef, label %left, label %right
+
----------------
Add a check not to show the second one being removed.
================
Comment at: test/Transforms/GuardWidening/basic.ll:42
@@ +41,3 @@
+
+; Like @f_1, but we have some non-trivial code we need to hoist before
+; we can widen a dominanting check.
----------------
Did you mean trivial here? An icmp is pretty easy to move around...
================
Comment at: test/Transforms/GuardWidening/basic.ll:97
@@ +96,3 @@
+; But hoisting out of control flow is fine if it makes a loop computed
+; condition loop invariant. This behavior may require some tuning in
+; the future.
----------------
Doing this here feels weird. This should be an addition to loop unswitching or possibly even LICM itself.
================
Comment at: test/Transforms/GuardWidening/basic.ll:121
@@ +120,3 @@
+
+; Hoisting out of control flow is also fine if we can widen the
+; dominating check without doing any extra work.
----------------
Note sure what you're getting at here. The branch condition could still correlate. Are you assuming healing? If so, comment.
================
Comment at: test/Transforms/GuardWidening/basic.ll:166
@@ +165,3 @@
+; CHECK: %cond_1 = load volatile i1, i1* %cond_buf
+; CHECK: %cond_3 = icmp ult i32 %a, 7
+; CHECK: %wide.chk = and i1 %cond_1, %cond_3
----------------
Wait what? A would absolutely expect cond_1 and cond_2 to be combined here. Why would I ever want to not do that?
http://reviews.llvm.org/D20143
More information about the llvm-commits
mailing list