[PATCH] D11706: [Unroll] Improve the brute force loop unroll estimate by propagating through PHI nodes across iterations.

[Chandler Carruth]

chandlerc added a comment.

Thanks, will submit with a minimal test case. See below for detailed replies.


================
Comment at: lib/Transforms/Scalar/LoopUnrollPass.cpp:551-553
@@ +550,5 @@
+  // this analysis.
+  assert(L->isLoopSimplifyForm() && "Must put loop into normal form first.");
+  assert(L->isLCSSAForm(DT) &&
+         "Must have loops in LCSSA form to track live-out values.");
+
----------------
mzolotukhin wrote:
> Shouldn't we just bail out in this case instead of crashing with assert?
> IOW, is it possible to make a loop, that won't be simplified, but will reach this point?
My intent is for that to be the responsibility of the caller.

In this case, a LoopPass operates under these specific invariants. This is why we require and preserve LoopSimplify and LCSSA above.

So currently, no, it isn't possible without a bug somewhere.

================
Comment at: test/Transforms/LoopUnroll/full-unroll-heuristics-phi-prop.ll:14-22
@@ +13,11 @@
+  %x0 = phi i64 [ 0, %entry ], [ %x9, %loop ]
+  %x1 = or i64 %x0, 1
+  %x2 = or i64 %x1, 2
+  %x3 = or i64 %x2, 3
+  %x4 = or i64 %x3, 4
+  %x5 = or i64 %x4, 5
+  %x6 = or i64 %x5, 6
+  %x7 = or i64 %x6, 7
+  %x8 = or i64 %x7, 8
+  %x9 = or i64 %x8, 9
+  %inc = add nuw nsw i64 %iv, 1
----------------
mzolotukhin wrote:
> Maybe just leave first 2-3 of them to make the test shorter?
> ```
> %x1 = or i64 %x0, 1
> %x2 = or i64 %x1, 2
> ```
> 
I mostly wanted it to be more clear that these couldn't just be simplified via SCEV. The add and icmp are simplified already for example. I'll see if there is a useful smaller number that still clearly fails without my change.


http://reviews.llvm.org/D11706