This is pretty much a carbon copy of the current pass manager pipeline, and it unblocks my testing. Passes not yet ported or disabled because of problems with the loop PM are marked with a FIXME. So, not complete, but hopefully a starting point. For those watching, this is so that I can start playing with PGO support in the new inliner (at LTO time).
The two problems are largely orthogonal. This is a port of the old LTO pipeline to the new pass manager. The aim is to make sure the current LTO pipeline works correctly with the new pass manager. I prefer to keep the old functionality in the new pass manager until it stabilizes. After that (or in parallel), we can decide whether we want to unify the two pipelines (if it's possible/reasonable).
On top of that, currently plugging the ThinLTO pipeline for LTO results in 2x/2.5x increase in compile time. Definitely not an hit I want to pay.
|553 ↗||(On Diff #85304)|
If you mean, in the caller of buildLTODefaultPipeline, then answer is yes (see my other patch for lib/LTO.
|575 ↗||(On Diff #85304)|
Yes, nice catch. I originally created this one as I thought we were running multiple CGSCC passes, but it turns out we just run PostOrderFunctionAttrs so that can be folded into the only argument of createModuleToPostOrderCGSCCPassAdaptor().
|619 ↗||(On Diff #85304)|
We used to. But it wasn't ported to the new PM and Chandler is not entirely convinced it's worth running this anymore (see the comment in the perModulePipeline).
I would suggest basic testing here similar to what we do for O[1-3sz] in test/Other/new-pm-defaults.ll. I'd keep the pre-link-LTO and non-LTO in that file and add a new file (new-pm-lto-defaults.ll) for the post-link LTO pipeline.
|672 ↗||(On Diff #85304)|
Typo here: assumptions -> Assumptions