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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri marked an inline comment as done.
lebedev.ri added a comment.

In D99249#2652350 <https://reviews.llvm.org/D99249#2652350>, @mkazantsev wrote:

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

@mkazantsev thank you for taking a look!



================
Comment at: llvm/lib/Passes/PassBuilder.cpp:579
   // TODO: Investigate promotion cap for O1.
   LPM1.addPass(LICMPass(PTO.LicmMssaOptCap, PTO.LicmMssaNoAccForPromotionCap));
   LPM1.addPass(SimpleLoopUnswitchPass());
----------------
mkazantsev wrote:
> 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.
Looking at `asm-printer.EmittedInsts` and `instcount.TotalInsts`,
we quite clearly end up with less instructions in either of
the `LICM-LoopRotate` and `LICM-LoopRotate-LICM`
(as compared to the baseline of `LoopRotate-LICM`),
and `LICM-LoopRotate-LICM` is clearly a winner overall.
Which is why that is the config i'm proposing here.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99249