[PATCH] D33540: [PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc created this revision.
Herald added subscribers: inglorion, Prazek, mcrosier.

Based on the original patch by Davide, but I've adjusted the API exposed
to just be different entry points rather than exposing more state
parameters. I've factored all the common logic out so that we don't have
any duplicate pipelines, we just stitch them together in different ways.
I think this makes the build easier to reason about and understand.

This adds a direct method for getting the module simplification pipeline
as well as a method to get the optimization pipeline. While not my
express goal, this seems nice and gives a good place comment about the
restrictions that are imposed on them.

I did make some minor changes to the way the pipelines are structured
here, but hopefully not ones that are significant or controversial:

1. I sunk the PGO indirect call promotion to only be run when we have PGO enabled (or as part of the special ThinLTO pipeline).

2. I made the extra GlobalOpt ron in ThinLTO just happen all the time and at a slightly more powerful place (before we remove available externaly functions). This seems like general goodness and not a big compile time sink, so it didn't make sense to *only* use it in ThinLTO. Fewer differences in the pipeline makes everything simpler IMO.

3. I hoisted the ThinLTO stop point pre-link above the partial inliner and the RPO function attr inference. Partial inlining isn't going to make the code smaller and it seems better to just do that once post-link. And the RPO inference won't infer anything terribly meaningful pre-link (recursiveness?) so it didn't make a lot of sense. But if teh RPO inference starts to matter, we should move it to the canonicalization phase anyways which seems like a better place for it (and there is a FIXME to this effect!). But that seemed a bridge too far for this patch.

If we ever need to parameterize these pipelines more heavily, we can
always sink the logic to helper functions with parameters to keep those
parameters out of the public API. But the changes above seemed minor
that we could possible get away without the parameters entirely.

Lastly, this factoring does introduce a nesting layer of module pass
managers in the default pipeline. I don't think this is a big deal and
the flexibility of decoupling the pipelines seems easily worth it.


https://reviews.llvm.org/D33540

Files:
  include/llvm/Passes/PassBuilder.h
  lib/LTO/LTOBackend.cpp
  lib/Passes/PassBuilder.cpp
  test/Other/new-pm-defaults.ll
  test/ThinLTO/X86/error-newpm.ll
  test/ThinLTO/X86/newpm-basic.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D33540.100214.patch
Type: text/x-patch
Size: 15433 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170525/60beef68/attachment.bin>