[PATCH] D146776: [llvm] Preliminary fat-lto-objects support

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

Right, I think we basically have two options on how to do this:

1. Make fat LTO exactly equivalent to LTO bitcode + default-optimized object code. This would require cloning the input module, running the LTO pipeline on one module, embedding the bitcode in the other and then running the default pipeline in that one. This will robustly match the LTO/default behavior exactly, at the cost of compile-time.
2. Make fat LTO approximately equivalent to LTO bitcode + default-optimized object code, with the usual cost-benefit tradeoffs. In this case, I don't think that rerunning module simplification after embedding bitcode makes much sense, because the differences between the pre-link ThinLTO pipeline and the default pipeline are too minor.

I believe the differences are:

- Various bits related to SamplePGO.
- The (currently disabled) MemProfiler pass. This looks like a plain bug to me: What is an instrumentation pass doing in the simplification pipeline? I'm pretty sure this should be in the optimization pipeline instead. Even if not, we could easily explicitly run this one, because it's at the very end of the simplification pipeline.
- A single GlobalDCE pass at the end of the pipeline. I'm pretty sure this is another bug, because the comment says "Remove dead code, except in the ThinLTO pre-link pipeline where we may want to keep available_externally functions", even though available_externally functions only become relevant post-link, not pre-link.
- Loop rotation will not duplicate calls in headers pre-link.

Ignoring the bugs, the only substantial differences seem to be related to SamplePGO, which I'm not familiar with. I'm not clear on how SamplePGO relates to fat LTO usage scenarios.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146776/new/

https://reviews.llvm.org/D146776