[PM] Introduce a reasonable port of the main per-module pass pipeline
authorChandler Carruth <chandlerc@gmail.com>
Thu, 22 Dec 2016 06:59:15 +0000 (06:59 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Thu, 22 Dec 2016 06:59:15 +0000 (06:59 +0000)
commite3f5064b723536b34a9477c884b920938601b3fe
treec341bc44cf7a7d62faa28cb23761fd9aa5b4df94
parent5542da4bbce35f0c54e0d558368d552e1ca023e3
[PM] Introduce a reasonable port of the main per-module pass pipeline
from the old pass manager in the new one.

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.

Differential Revision: https://reviews.llvm.org/D28042

llvm-svn: 290325
llvm/include/llvm/Analysis/LoopPassManager.h
llvm/include/llvm/Passes/PassBuilder.h
llvm/include/llvm/Transforms/Scalar/LoopRotation.h
llvm/lib/Analysis/LoopPassManager.cpp
llvm/lib/Passes/PassBuilder.cpp
llvm/lib/Transforms/Scalar/LoopRotation.cpp
llvm/test/Other/new-pass-manager.ll
llvm/unittests/Analysis/LoopPassManagerTest.cpp