[Polly] Introduce PhaseManager and remove LPM support

[Meinersbur]

Instead of relying on any pass manager to schedule Polly's passes, add Polly's own pipeline manager which is seen as a monolithic pass in LLVM's pass manager. Polly's former passes are now phases of the new PhaseManager component.

Relying on LLVM's pass manager (the legacy as well as the New Pass Manager¹) to manage Polly's phases never was a good fit that the PhaseManager resolves:

• Polly passes were modifying analysis results, in particular RegionInfo and ScopInfo. This means that there was not just one unique and "definite" analysis result, the actual result depended on which analyses ran prior, and the pass manager was not allowed to throw away cached analyses or prior SCoP optimizations would have been forgotten. The LLVM pass manger's persistance of analysis results is not contractual but designed for caching.

• Polly depends on a particular execution order of passes and regions (e.g. regression tests, invalidation of consecutive SCoPs). LLVM's pass manager does not guarantee any excecution order.

• Polly does not completely preserve DominatorTree, RegionInfo, LoopInfo, or ScalarEvolution, but only as-needed for Polly's own uses. Because the ScopDetection object stores references to those analyses, it still had to lie to the pass manager that they would be preserved, or the pass manager would have released and recomputed the invalidated analysis objects that ScopDetection/ScopInfo was still referencing. To ensure that no non-Polly pass would see these not-completely-preserved analyses, all analyses still had to be thrown away after the ScopPassManager, respectively with a BarrierNoopPass in case of the LPM.

• The NPM's PassInstrumentation wraps the IR unit into an llvm::Any object, but implementatons such as PrintIRInstrumentation call llvm_unreachable on encountering an unknown IR unit, such as SCoPs, with no extension points to add support. Hence LLVM crashes when dumping IR between SCoP passes (such as -print-before-changed with Polly being active).

The new PhaseManager uses some command line options that previously belonged to Polly's legacy passes, such as -polly-print-detect (so the option will continue to work). Hence the LPM support is incompatible with the new approach and support for it is removed.

PRs from this patch series:

• [Polly] Remove PolyhedralInfo #124437
• [Polly] Update ScopInliner for NPM #125427
• [Polly][CodePreparation] Extract common code of LPM and NPM #140419
• [Polly] Introduce PhaseManager and remove LPM support #125442 (this PR)
• [Polly] Remove ScopPass infrastructure #125783

Footnotes

1. When Chandler Carruth announced working on the NPM, I talked to him about supporting Polly's use cases. His response was "passes must adhere to the constraints of the pass manager". ↩

[kartcq]

[like] Karthika Devi C reacted to your message:

…

________________________________ From: Eli Friedman ***@***.***> Sent: Monday, February 3, 2025 1:40:45 AM To: llvm/llvm-project ***@***.***> Cc: Karthika Devi C (QUIC) ***@***.***>; Review requested ***@***.***> Subject: Re: [llvm/llvm-project] [Polly] Introduce PhaseManager and remove LPM support (PR #125442) WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. @efriedma-quic<https://github.com/efriedma-quic> requested your review on: #125442<#125442> [Polly] Introduce PhaseManager and remove LPM support. — Reply to this email directly, view it on GitHub<#125442 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXW3Q47JNLHXTDSBTI26WP32N3CJ3AVCNFSM6AAAAABWK6V7R6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJWGE2TINRYGYYDGOA>. You are receiving this because your review was requested.Message ID: ***@***.***>

[Meinersbur]

FYI, @rahulana-quic @tobiasgrosser

For some reason I cannot add you as reviewers, but feel free to start a review.

[kartcq]

Hi @Meinersbur
As the change is huge, please give us some time to try it out downstream before merging.
Thanks.

[Meinersbur]

OK, please signal your LGTM when you are ready

[kartcq]

Thanks for your patience @Meinersbur.
I am posting some of my observations as review comments.

[kartcq]

This way of computing ScopInfo processes the regions in same order, as opposed to reverse order, followed by FunctionToScopPassAdaptor earlier.
To pertain to old behaviour, can we either invoke ScopBuilder in reverse order here or change the order in ScopInfo::recompute.

[Meinersbur]

Can you clarify? There are two places we iterate over scops:

1. For -print-scops: This PR's code reuses the LPM did:

   llvm-project/polly/lib/Pass/PhaseManager.cpp

   Line 131 in 5a91ecf

   addRegionIntoQueue(*TLR, Regions);

   vs
   

   llvm-project/llvm/lib/Analysis/RegionPass.cpp

   Line 62 in 4504e77

   addRegionIntoQueue(*RI->getTopLevelRegion(), RQ);

2. For the phase pipeline itself it resuses the code from the NPM/FunctionToScopPassAdaptor:

   llvm-project/polly/lib/Pass/PhaseManager.cpp

   Lines 148 to 158 in 5a91ecf

   	SmallPriorityWorklist<Region *, 4> Worklist;
   	for (auto &[R, S] : Info)
   	if (S)
   	Worklist.insert(R);
   	auto &&TTI = FAM.getResult<TargetIRAnalysis>(F);
   	while (!Worklist.empty()) {
   	Region *R = Worklist.pop_back_val();
   	if (!SD.isMaxRegionInScop(*R, /*Verify=*/false))
   	continue;
   	Scop *S = Info.getScop(R);

   vs
   

   llvm-project/polly/include/polly/ScopPass.h

   Lines 238 to 259 in 4504e77

   	SmallPriorityWorklist<Region *, 4> Worklist;
   	for (auto &S : SI)
   	if (S.second)
   	Worklist.insert(S.first);
   	ScopStandardAnalysisResults AR = {AM.getResult<DominatorTreeAnalysis>(F),
   	AM.getResult<ScopInfoAnalysis>(F),
   	AM.getResult<ScalarEvolutionAnalysis>(F),
   	AM.getResult<LoopAnalysis>(F),
   	AM.getResult<RegionInfoAnalysis>(F),
   	AM.getResult<TargetIRAnalysis>(F)};
   	ScopAnalysisManager &SAM =
   	AM.getResult<ScopAnalysisManagerFunctionProxy>(F).getManager();
   	SPMUpdater Updater{Worklist, SAM};
   	while (!Worklist.empty()) {
   	Region *R = Worklist.pop_back_val();
   	if (!SD.isMaxRegionInScop(*R, /*Verify=*/false))
   	continue;
   	Scop *scop = SI.getScop(R);

[kartcq]

It's in second case for pass pipeline, the order is changed.