This is an archive of the discontinued LLVM Phabricator instance.

[llvm] Factor out inlining pipeline as a module pipeline.
ClosedPublic

Authored by mtrofin on Apr 20 2020, 12:34 PM.

Details

Summary

This simplifies testing in scenarios where we want to set up module-wide analyses for inlining. The patch enables treating inlining and its function cleanups, as a module pass. The alternative would be for tests to describe the pipeline, which is tedious and adds maintenance
overhead.

The patch does not change what passes are run, or in what order, but it is detectable (see test changes), so it is *almost* NFC.

Diff Detail

Event Timeline

mtrofin created this revision.Apr 20 2020, 12:34 PM

What about the old pass manager?

llvm/test/Other/new-pm-defaults.ll
136

This is not strictly speaking NFC. You could pass the ModulePassManager to the buildInlinerPipeline though.

mtrofin marked 2 inline comments as done.Apr 21 2020, 10:13 AM
mtrofin added inline comments.
llvm/test/Other/new-pm-defaults.ll
136

That wouldn't allow us to treat the output of buildInlinerPipeline as a pass.

Happy to remove the 'NFC'. So I learn - can structural changes to the pipeline account for any practically detectable functionality change (other than this here, which is observable by logs)?

mtrofin retitled this revision from [llvm][NFC] Factor out inlining pipeline as a module pipeline. to [llvm] Factor out inlining pipeline as a module pipeline..Apr 21 2020, 12:18 PM
mtrofin edited the summary of this revision. (Show Details)
mtrofin updated this revision to Diff 259351.Apr 22 2020, 12:00 PM
mtrofin marked an inline comment as done.

Added an example use of the pass manager posing as a pass, and a test.

Just a couple of suggestions for comment clarifications in the new test. I see that @jdoerfert asked whether this should be done for the old PM too. Would that make sense?

llvm/test/Transforms/Inline/module-inlining.ll
2

"At most with just the inliner pass"?

4

"In contrast, with the full set of module inliner related passes, ..."?

mtrofin marked 2 inline comments as done.Apr 23 2020, 8:22 AM

Just a couple of suggestions for comment clarifications in the new test. I see that @jdoerfert asked whether this should be done for the old PM too. Would that make sense?

I can't seem to find @jdoerfert's question about the old PM - I only see the comment about NFC. Sorry if I missed it (am I not using phabricator correctly?)

To answer the question, the tests in the ML work outlined in D77752 would be the main intended consumer. That work was only tailored to the new pass manager. It's a fair point to talk about whether to port that to the legacy PM, and what would testing look like there, but I think it's premature to do so at this point.

If a different scenario arises requiring a similar factoring, we can always add the code then.

What about the old pass manager?

Sorry, I didn't see this, until @tejohnson pointed it out (thanks!)

Answered there.

tejohnson accepted this revision.Apr 23 2020, 8:42 AM

lgtm, but please wait and see if @jdoerfert has any follow up

This revision is now accepted and ready to land.Apr 23 2020, 8:42 AM
davidxl added inline comments.Apr 23 2020, 10:00 AM
llvm/lib/Passes/PassRegistry.def
85

Why oz? Perhaps barebone-scc-inliner ?

mtrofin marked 2 inline comments as done.Apr 23 2020, 10:21 AM
mtrofin added inline comments.
llvm/lib/Passes/PassRegistry.def
85

because I'm passing OptimizationLevel::Oz. If we want other OptimizationLevels, we'd add other names, e.g. MODULE_PASS("scc-o3-module-inliner", etc. We start with -oz because I plan on leveraging this for the ML patches.

...if there's a way to pass the optimization level otherwise, happy to do that instead.

mtrofin marked an inline comment as done.Apr 23 2020, 11:03 AM
davidxl accepted this revision.Apr 24 2020, 8:58 AM

lgtm

What about the old pass manager?

Sorry, I didn't see this, until @tejohnson pointed it out (thanks!)

Answered there.

I haven't heard back, so I'll go ahead and land this, if that's OK - happy to follow-up on the legacy PM discussion afterwards!

This revision was automatically updated to reflect the committed changes.