[PATCH] D9151: Loop Versioning for LICM
Mehdi AMINI via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 12 22:36:57 PST 2016
joker.eph added inline comments.
================
Comment at: lib/Transforms/IPO/PassManagerBuilder.cpp:349
@@ -342,1 +348,3 @@
+ MPM.add(createLICMPass()); // Hoist loop invariants
+ }
if (!DisableUnitAtATime && OptLevel > 1 && !PrepareForLTO) {
----------------
ashutosh.nema wrote:
> joker.eph wrote:
> > Why is is done here and not where LICM is usually done? Line 419?
> > Did you try multiple placements? Do you have benchmarks results that drives this choice?
> We want to run this when inining is over, because after that we may see more accurate aliasing.
> That’s why we placed it after ‘createBarrierNoopPass’. If we do this earlier probably of no-alias
> aliasing assumptions in version loop, other optimizations may get some benefit.
>
> This can be schedule later as well but I don’t see any benefit.
>
> We have observed good gains in our internal benchmarks, mostly based on customer workloads.
I'm not sure I follow why you need the inliner to be fully complete over the whole module and not having processed the function on which you want to run LICM. What kind of aliasing will this avoid? Do you have an example?
Also, you are saying that you don't see any benefit of scheduling this later, can you elaborate with respect to the other run of LICM I pointed?
Also, I ask about benchmark with respect to the different possible placement for this pass, and you didn't answer this in particular.
Repository:
rL LLVM
http://reviews.llvm.org/D9151
More information about the llvm-commits
mailing list