[PATCH] D45210: [New-PM] Lift Scop Pipeline to CGSCC-level

[Lukas Böhm via Phabricator via llvm-commits]

lksbhm added a comment.

> Would it make sense to keep code that analyzes SCoP's function-wise and only use a CGSCC pass when interprocedural analysis is enabled?

Our approach doesn't actually change the level at which scop analysis happens, if that is the question. I.e. `ScopInfoAnalysis` remains a function analysis. The only reason we want to process the callgraph at cgscc-level when running a scop pass pipeline is the guaranteed ordering which maximizes the callee ScopInfo availability. Or, from the implementation point of view, we cannot run `ScopInfoAnalysis` on-demand for a callee but instead have to depend on it already having run before. This is where cgscc's post-order traversal comes in handy.
However, if you're asking whether it would make sense to have both `FunctionToScopPassAdaptor` alongside `CGSCCToScopPassAdaptor`, this might be something worth considering.

> Similar to the "summary functions" in PENCIL <https://hal.inria.fr/hal-01133962/file/ppcg-pencil-v2.pdf>.

>From quickly glancing at the paper you linked to, the "function summaries" section seems very related to our approach :)

> Another possibility would have been to inline the callee's scop to get a single scop. We already have a 'hack' for this called `ScopInliner`.

I'm not familiar with the way `ScopInliner` works. I'm assuming this is on llvm IR level(?)


Repository:
  rPLO Polly

https://reviews.llvm.org/D45210