Preemptively switch 2 tests to the new PM
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
380 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
Thanks for looking into this!
I was previously worried that modifying the IR in pass instrumentation would be bad, but maybe it's ok? The biggest thing I was worried about was unintentionally invalidating analyses, but it looks like both debugify passes preserve all analyses, so it might be ok.
I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.
DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.
llvm/test/DebugInfo/debugify-export.ll | ||
---|---|---|
1 | We should keep the legacy PM RUN line since its implementation is so different. Then use regex to check that we're running a verifier pass. |
Yeah I was a bit concerned as well. The code says PreservedAnalyses::all() so may be it is fine? The dirty part is the const_cast.
I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.
DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.
-debugify-export writes a file. So even if it is moved to StandardInstrumentations, all the users (clang/opt newPM/opt legacyPM) will need to do something with the option.
Ah I see, that makes sense.
I still think DebugifyEachInstrumentation should be treated in StandardInstrumentations like the others, and DebugifyEachInstrumentation::registerCallbacks can check the flags to enable/disable itself.
Emmm. Since we don't really benefit from having the code StandardInstrumentations (using -debugify-export requires the knowledge about DebugifyStatsMap), having the code in Debugify.cpp is fine?
The implementation is actually all in Debugify.cpp . Having DebugifyEachInstrumentation can make StandardInstrumentations unaware of DebugInfo, which achieves good isolation.
This allows us to make apply* and check* static after legacy PM debugify code in opt.cpp is removed.
The issue I have is that the flags can be used anywhere, but each user of StandardInstrumentations has to manually register DebugifyEachInstrumentation if they want to use it. I'd prefer either that the flags be opt-specific and opt can register DebugifyEachInstrumentation, or the flags move to Debugify.cpp so any user of PassBuilder can use them and StandardInstrumentations handle DebugifyEachInstrumentation so that not every user of PassBuilder has to remember to use it.
Thanks! This argument makes sense. I moved the two cl::opt options from Debugify.cpp to opt since clang cannot really use them (well, probably it could with some efforts, but that shall belong to a separate change).
Since only opt knows about debugify, it makes sense to have a DebugifyEachInstrumentation.
lgtm besides comments about tests
llvm/test/DebugInfo/pr37964.ll | ||
---|---|---|
1 | -passes=gvn instead of -gvn -enable-newpm=1 |
We should keep the legacy PM RUN line since its implementation is so different. Then use regex to check that we're running a verifier pass.