[PATCH] D16300: Enable LoopLoadElimination by default

Adam Nemet via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 19 14:50:29 PST 2016


anemet added a comment.

In http://reviews.llvm.org/D16300#330374, @reames wrote:

> Just to make sure I understand, LLE is effectively a specialized form of 
>  PRE targeted at loops, but with the additional flexibility to introduce 
>  runtime checks to resolve aliasing queries?  Is that a correct rephrasing?


That is correct.  The idea is also to allow PRE between non-adjacent iterations so another way to look at the problem this pass solves is loop-aware scalar replacement (with versioning).

> Have you examined how much of the benefit comes from the runtime 

>  checks?


I would expect most of the cases require run-time checks right now because Load-PRE currently performs a similar optimization without checks during the canonicalization phase so it steals most of those opportunities.  Long term, the hope is that loop Load-PRE will be removed in favor of this pass at which point those cases will fall on this pass too.

For the record, I did look at the benchmarks mentioned in the description and out of those hmmer and adi require memchecks while dynprog does not.

> I'd be very tempted to introduce an aggressive and a 

>  non-aggressive form which differ only in whether they insert runtime 

>  checks.  I'm concerned by the potential code size and compile time 

>  impact of aggressive code duplication.


That's reasonable.  Are you thinking of disabling if SizeLevel is set (i.e. -Os or -Oz) or something different.

> Has this been stress tested by doing (for instance) a clang self host?  

>  Sorry if this has been addressed earlier, I don't see it mentioned 

>  specifically here and haven't read back through the history.


Yes I've done a self-host but I never mentioned it.

Thanks for your feedback,
Adam


http://reviews.llvm.org/D16300





More information about the llvm-commits mailing list