Depends on D28996.
With this in, we can teach the gold plugin and lld about the new PM and start to experiment with that.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/LTO/LTOBackend.cpp | ||
---|---|---|
248 ↗ | (On Diff #85308) | In the meantime, we shouldn't accept the combination ThinLTO+Conf.OptUseNewPM. |
lib/LTO/LTOBackend.cpp | ||
---|---|---|
248 ↗ | (On Diff #85308) | Indeed. Are you fine with this being a fatal error for the time being as the configuration is forbidden (similarly to what we do around line 212)? |
FWIW, all of this seems fine. I don't have a lot of opinions about the best way to wire up the lib/LTO side, leaving that mostly to Mehdi.
lib/LTO/LTOBackend.cpp | ||
---|---|---|
248 ↗ | (On Diff #85308) | I'm fine with a report_fatal_error for this. |
lib/LTO/LTOBackend.cpp | ||
---|---|---|
248 ↗ | (On Diff #85308) | The issue for ThinLTO seems larger than just not having the summary plumbed through (it isn't being used yet in the new pass manager pipeline set up in D28996 in any case, since the LowerTypeTestsPass is currently disabled there). The bigger issue is that a new pass manager pipeline for ThinLTO (analogous to the one for LTO added in D28996) needs to be set up. Can you add a FIXME by the fatal error about this? |
-> Addressed comments (Teresa/Mehdi)
-> Added a cl::opt so that we don't have to teach linkers about the new pm
-> Added basic testing
PTAL
A couple of nits, otherwise LGTM
lib/LTO/LTOBackend.cpp | ||
---|---|---|
46 ↗ | (On Diff #85434) | Maybe more explicit "Run LTO passes using..." |
test/ThinLTO/X86/error-newpm.ll | ||
13 ↗ | (On Diff #85434) | Seems like this test could be even simpler since we are just checking for an error (i.e. a single function). Alternatively, if we want to instead make this a test that will eventually test the new PM when it is implemented for ThinLTO, maybe the file name should be changed to just "newpm.ll"? |