ping

I don't understand the non-deterministic part, but otherwise this makes sense

In D94266#2507718, @Meinersbur wrote:

Note that for same passes, there Polly has NPM equivalents. E.g. -polly-prepare has -passes=polly-prepare, -polly-scops has -passes='scop(print<polly-scops>)'.

Assuming this is the accepted workaround for the NPM transition (I personally think it is ugly), this looks fine for the Polly side of things.

address comments

@sbc100 is this ok?

https://reviews.llvm.org/D94825

https://reviews.llvm.org/D94825

just a general comment, I do like the idea of printing diffs between passes, could make looking through pipelines much nicer

overall looks good, just a couple small comments

ping

Wondering if this makes sense to you (before I go and finish cleaning up all the tests)

comment fixups
move max BB check into areInlineCompatible

It's not an emergency.
The issue with InlineAdvisorAnalysis is that the ModuleInlineWrapperPass presets the InliningAdvisorMode of the InlineAdvisorAnalysis. We could force override it, but then what's the point of InlineAdvisorAnalysis? Can't we just create an InlineAdvisor in the pass itself rather than using a wrapper like InlineAdvisorAnalysis?

An alternative is to run the mandatory inliner in the same CGSCC pipeline as everything else, but the way InlineAdvisorAnalysis is setup made it hard to implement

In D94644#2497125, @mtrofin wrote:

Would running the function simplification pipeline after the always inline pass address the issue?

test fix

fix ARM unswitch test: looks like minsize functions are becoming smaller, which is good

rebase past https://reviews.llvm.org/D94187

is this good to go?

In D94448#2494328, @nikic wrote:

FYI this change had some pretty significant impact on compile-time (https://llvm-compile-time-tracker.com/compare.php?from=4718ec01669b01373180f4cd1256c6e2dd6f3999&to=f748e92295515ea7b39cd687a718915b559de6ec&stat=instructions) and code size (https://llvm-compile-time-tracker.com/compare.php?from=4718ec01669b01373180f4cd1256c6e2dd6f3999&to=f748e92295515ea7b39cd687a718915b559de6ec&stat=size-text). Is that expected?

In D93946#2492918, @sanwou01 wrote:

Hi folks, I'm afraid an 8% regression in h264ref (SPEC INT 2006) bisects to this patch. This in on AArch64 with -flto on a Neoverse-N1 based system, but I wouldn't be surprised if this showed up elsewhere too.

How do people feel about reverting the patch while we investigate the regression? To start with, I'll try to find out why this has caused the drop in performance: it doesn't seem immediately obvious to me.

parameter comment

In D93743#2487987, @ahatanak wrote:

LGTM. ARC contract pass isn't being run by the NPM, but you are going to change that in the future, I guess?

In D94283#2486053, @ychen wrote:

LGTM. I still think we should get back to the legacy names so that translation is avoided.

WDYT about adding optnone to all functions except the ones you're interested in? Would that cut down the compile times?
We could reuse ForceFunctionAttrsPass rather than adding so much plumbing. This is too much plumbing for my liking.

In D93743#2485876, @ahatanak wrote:

Is this change safe considering calls to EP.get() can add function declarations to the module as you mentioned in https://reviews.llvm.org/D86178?

In D93929#2485715, @quic_aankit wrote:

@asbirlea I remember that HexagonVLCR pass has a dependency on LCSSA and LoopSimplifyPass. Is there any way we can run these passes too at LoopOptimizerEndEP? If not maybe use another EP for legacy PM? I'm not sure if the below code would run these passes in the correct order as well

PB.registerOptimizerLastEPCallback(
    [=](ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
      LoopPassManager LPM(DebugPassManager);
      FunctionPassManager FPM(DebugPassManager);
      LPM.addPass(HexagonVectorLoopCarriedReusePass());
      FPM.addPass(LoopSimplifyPass());
      FPM.addPass(LCSSAPass());
      FPM.addPass(createFunctionToLoopPassAdaptor(std::move(LPM)));
      MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
    });

@pranavb Can you comment more on this?

rebase
make function static

Was split into multiple changes

I suppose doing some benchmarking would be ideal, but this makes sense, I can't imagine why these sorts of functions wouldn't be inlined other than attributes like coldcc/noinline.