[PATCH] D16300: Enable LoopLoadElimination by default

[Philip Reames via llvm-commits]

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?

Have you examined how much of the benefit comes from the runtime 
checks?  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.

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.

On 01/18/2016 12:15 PM, Adam Nemet via llvm-commits wrote:
> anemet created this revision.
> anemet added reviewers: dberlin, hfinkel.
> anemet added a subscriber: llvm-commits.
> Herald added subscribers: joker.eph, aemerson.
>
> If you're interested to benchmark this yourself, you can enable the pass
> with -mllvm -enable-loop-load-elim currently.  Please let me know if you
> see any regressions.
>
> I re-benchmarked this and results are similar to original results in
> D13259:
>
> On ARM64:
>    SingleSource/Benchmarks/Polybench/linear-algebra/solvers/dynprog -59.27%
>    SingleSource/Benchmarks/Polybench/stencils/adi                   -19.78%
>
> On x86:
>    SingleSource/Benchmarks/Polybench/linear-algebra/solvers/dynprog  -27.14%
>
> And of course the original ~20% gain on SPECint_2006/456.hmmer with Loop
> Distribution.
>
> In terms of compile time, there is ~5% increase on both
> SingleSource/Benchmarks/Misc/oourafft and
> SingleSource/Benchmarks/Linkpack/linkpack-pc.  These are both very tiny
> loop-intensive programs where SCEV computations dominates compile time.
>
> The reason that time spent in SCEV increases has to do with the design
> of the old pass manager.  If a transform pass does not preserve an
> analysis we *invalidate* the analysis even if there was *no*
> modification made by the transform pass.
>
> This means that currently we don't take advantage of LLE and LV sharing
> the same analysis (LAA) and unfortunately we recompute LAA *and* SCEV
> for LLE.
>
> (There should be a way to work around this limitation in the case of
> SCEV and LAA since both compute things on demand and internally cache
> their result.  Thus we could pretend that transform passes preserve
> these analyses and manually invalidate them upon actual modification.
> On the other hand the new pass manager is supposed to solve so I am not
> sure if this is worthwhile.)
>
> http://reviews.llvm.org/D16300
>
> Files:
>    lib/Transforms/IPO/PassManagerBuilder.cpp
>
> Index: lib/Transforms/IPO/PassManagerBuilder.cpp
> ===================================================================
> --- lib/Transforms/IPO/PassManagerBuilder.cpp
> +++ lib/Transforms/IPO/PassManagerBuilder.cpp
> @@ -102,8 +102,8 @@
>           "Enable the GlobalsModRef AliasAnalysis outside of the LTO pipeline."));
>   
>   static cl::opt<bool> EnableLoopLoadElim(
> -    "enable-loop-load-elim", cl::init(false), cl::Hidden,
> -    cl::desc("Enable the new, experimental LoopLoadElimination Pass"));
> +    "enable-loop-load-elim", cl::init(true), cl::Hidden,
> +    cl::desc("Enable the LoopLoadElimination Pass"));
>   
>   PassManagerBuilder::PassManagerBuilder() {
>       OptLevel = 2;
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160119/b4b846c2/attachment.html>