This is an archive of the discontinued LLVM Phabricator instance.

[PM] Introduce a reasonable port of the main per-module pass pipeline from the old pass manager in the new one.
ClosedPublic

Authored by chandlerc on Dec 21 2016, 5:54 PM.

Details

Summary

I'm not trying to support (initially) the numerous options that are
currently available to customize the pass pipeline. If we end up really
wanting them, we can add them later, but I suspect many are no longer
interesting. The simplicity of omitting them will help a lot as we sort
out what the pipeline should look like in the new PM.

I've also documented to the best of my ability *why* each pass or group
of passes is used so that reading the pipeline is more helpful. In many
cases I think we have some questionable choices of ordering and I've
left FIXME comments in place so we know what to come back and revisit
going forward. But for now, I've left it as similar to the current
pipeline as I could.

Lastly, I've had to comment out several places where passes are not
ported to the new pass manager or where the loop pass infrastructure is
not yet ready. I did at least fix a few bugs in the loop pass
infrastructure uncovered by running the full pipeline, but I didn't want
to go too far in this patch -- I'll come back and re-enable these as the
infrastructure comes online. But I'd like to keep the comments in place
because I don't want to lose track of which passes need to be enabled
and where they go.

One thing that seemed like a significant API improvement was to require
that we don't build pipelines for O0. It seems to have no real benefit.

I've also switched back to returning pass managers by value as at this
API layer it feels much more natural to me for composition. But if
others disagree, I'm happy to go back to an output parameter.

I'm not 100% happy with the testing strategy currently, but it seems at
least OK. I may come back and try to refactor or otherwise improve this
in subsequent patches but I wanted to at least get a good starting point
in place.

Event Timeline

chandlerc updated this revision to Diff 82298.Dec 21 2016, 5:54 PM
chandlerc retitled this revision from to [PM] Introduce a reasonable port of the main per-module pass pipeline from the old pass manager in the new one..
chandlerc updated this object.
chandlerc added a reviewer: mehdi_amini.
chandlerc added a subscriber: llvm-commits.
mehdi_amini added inline comments.Dec 21 2016, 9:34 PM
lib/Passes/PassBuilder.cpp
374

Technically the default -O{1,2,3} pipeline starts with populateFunctionPassManager (which runs -simplifycfg -domtree -sroa -early-cse -lower-expect)

773

Shame on you for not supporting ThinLTO! :p
OK, shame on me for not submitting a patch earlier...

chandlerc added inline comments.Dec 21 2016, 9:36 PM
lib/Passes/PassBuilder.cpp
374

I have that here in EarlyFPM. I just lifted the Force and Infer up because they are designed to be "as early as possible" but were module passes and so challenging before.

773

Happy for you to work on this, or happy to port that part of the existing PMB when I get to it. I mostly wanted to get enough to test stuff "in the wild".

mehdi_amini accepted this revision.Dec 21 2016, 10:09 PM
mehdi_amini edited edge metadata.

LGTM, I think that'll be a good starting point for experimentation :)

lib/Passes/PassBuilder.cpp
374

Oh right, I missed it because of the motion of the FunctionAttrs passes.

This revision is now accepted and ready to land.Dec 21 2016, 10:09 PM
This revision was automatically updated to reflect the committed changes.