[PATCH] D99249: [PassManager] Run additional LICM before LoopRotate

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev added a comment.

Looks nice for me, but let's wait for Alina's investigation to get concluded.



================
Comment at: llvm/lib/Passes/PassBuilder.cpp:579
   // TODO: Investigate promotion cap for O1.
   LPM1.addPass(LICMPass(PTO.LicmMssaOptCap, PTO.LicmMssaNoAccForPromotionCap));
   LPM1.addPass(SimpleLoopUnswitchPass());
----------------
thopre wrote:
> lebedev.ri wrote:
> > thopre wrote:
> > > mkazantsev wrote:
> > > > Theroretically LICM should move all invariants out of loop, and loop rotation should not create any new invariants. Do we really need this again?
> > > Load of size >4 whose base pointer is derived from the `this` pointer fail the isSafeToExecuteUnconditionally() in LICM because the alignment of the `this` is 1.
> > > Theroretically LICM should move all invariants out of loop, and loop rotation should not create any new invariants. Do we really need this again?
> > 
> > I think the numbers speak for themselves, see 3'rd table in the description i just added
> > that shows improvements when going from `LICM before LoopRotate` to `LICM after LoopRotate`.
> > Especially, note the `licm.NumSunk` (+30%), and note that there was no such regression
> > when just moving the LICM to before LoopRotate.
> > 
> Sorry I misread, you meant **moving** LICM before rather than **adding** a new LICM pass before.
I'm not sure of change of `licm.NumSunk` statistic either way is a regression or not. Its increase can either be "we somehow enabled more optimizations" or "we duplicated code and now sink duplicated values twice". Thinking more about it, I can imagine how rotate can turn a Phi into a sinkable loop invariant. So I guess it's fine to keep LICM after it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99249/new/

https://reviews.llvm.org/D99249