[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