[PATCH] D44983: [LoopUnroll] Only peel if a predicate becomes known in the loop body.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

In https://reviews.llvm.org/D44983#1051359, @mkazantsev wrote:

> I am not sure about the heuristic in general. This patch says that we peel out first `K` iterations if starting from `K + 1`th iteration the predicate becomes known false. But isn't in even more profitable to peel out `K+1`th iteration because the predicate that was trivially true on first iterations (and thus we could base optimizations on it) will be trivially false, and it will STILL allow you to base some optimizations on it.
>
> I think a better approach would be to peel out another iteration if we know that `Pred` is true on it OR if we know that `Pred` is false. Either will allow us to simplify the peeled code. Please correct me if I'm wrong with my reasoning.


I think I see what you mean. You are saying we would not have to stop peeling even once Pred changes from true to false, as the peeled code could be simplified still? We could, but I think the major benefit of this optimization would be to simplify the loop body and peeling more than necessary may prevent inlining due to the code size increase.

> I am not sure what problem you are fighting in this patch.

Basically, I want to prevent peeling, if after peeling, we cannot simplify the loop body. See the @test4. Here we would peel of a few iterations and the peeled code could be simplified, but we cannot simplify the loop body after peeling. So we potentially add  lots of additional instructions through peeling, with little benefit, if the trip count is large. And that may prevent inlining.



================
Comment at: lib/Transforms/Utils/LoopUnrollPeel.cpp:200
+    // or !Pred in the loop body statically.
+    unsigned NewPeelCount = DesiredPeelCount;
+
----------------
mkazantsev wrote:
> BTW, I just realized that this entire optimization will be harmful if the predicate is provable for `LeftAR, RightSCEV`. In this case, something is true on EVERY iteration, and you peel out SOME iterations thinking that it would be profitable.
> 
> Isn't it the real problem you are trying to win here?
Are you referring where either Pred or !Pred is known for `LeftAr, RightSCEV` independently of the iteration? This case should be guarded against in line 176


https://reviews.llvm.org/D44983