<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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?<br>
<br>
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. <br>
<br>
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. <br>
<br>
<div class="moz-cite-prefix">On 01/18/2016 12:15 PM, Adam Nemet via
llvm-commits wrote:<br>
</div>
<blockquote
cite="mid:differential-rev-PHID-DREV-2afy6qmajhr64ib4csjr-req@reviews.llvm.org"
type="cite">
<pre wrap="">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.)
<a class="moz-txt-link-freetext" href="http://reviews.llvm.org/D16300">http://reviews.llvm.org/D16300</a>
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;
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</body>
</html>