[PATCH] D43876: [LoopUnroll] Peel off iterations if it makes conditions true/false.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

Hi Chad,

In https://reviews.llvm.org/D43876#1045969, @mcrosier wrote:

> Hi Florian,
>  We identified a 2.15% regression in SPEC2006/h264ref due to this commit.  After this change, the FullPelBlockMotionBiPred() function is no longer inlined into the hottest function, BlockMotionSearch().  Previous to this change, the function was inlined because there was a single callsite in the entire program (known only when compiling in LTO) and the original definition could be removed after inlining.  However, after loop peeling the callsite of FullPelBlockMotionBiPred() is replicated, which prevents inlining.
>
> I was wondering if we could avoid peeling in this case until we have some type of cost model that can determine if peeling would prevent inlining.  Also, after looking at the code (which I can't share here) you might also notice that the amount of code being peeled in this case is fairly large relative to the amount of code being removed from the loop.  It might also make sense to have a heuristic that takes code size into consideration when peeling, if that hasn't already been done.
>
> Thoughts?


Thanks for making me aware of this, I originally thought considering MaxPeelCount should help us avoid those cases.

I will follow this up with patches in the following days. I think there are a couple of things that can be done to make the peeling more conservative for now. First, only peel if we can proof that the condition is known to be true in the peeled part and false in the loop (or vice versa). Otherwise we cannot simplify the loop body and peeling is likely not very beneficial. Second, have a simple cost function, that takes the size of the loop body vs the eliminated instructions into account.

Also, https://reviews.llvm.org/D43878, which enables induction variable simplification after peeling is not committed yet, so currently the loop body may not be simplified after peeling, even if it could be.

Cheers,
Florian


Repository:
  rL LLVM

https://reviews.llvm.org/D43876