Currently there is an issue where the legacy pass manager uses a different OptBisect counter than the new pass manager.
This fix makes the npm OptBisectInstrumentation use the global OptBisect.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for looking into this!
Can you upload the diff with full context (e.g. use diff -U 9999 or use arcanist to upload)?
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
1153 ↗ | (On Diff #310386) | I took another look, if you look in LLVMContextImpl::getOptPassGate, it says the OptBisect instance must outlive the LLVMContext, which isn't true here. There's actually a global OptBisect there that we should use. So I think we should go the opposite way. The NPM's StandardInstrumentations shouldn't contain its own OptBisect, it should inspect the IR it's receiving to get the IR's LLVMContext and call LLVMContext::getOptPassGate(). e.g. after unwrapping Any to Function *, F->getContext().getOptPassGate(). |
clang/test/CodeGen/new-pass-manager-O1-opt-bisect.c | ||
1 ↗ | (On Diff #310386) | Something like "Make sure opt-bisect works through both pass managers" is probably better. |
3 ↗ | (On Diff #310386) | don't need this |
3 ↗ | (On Diff #310386) | does this actually run the codegen passes? I thought we needed -emit-obj. |
Oh and in the description
This means that when using OptBisect under the NPM it runs twice when it should only run once.
doesn't really make sense. I'd say something like
e.g. -opt-bisect-limit=1 will run both the first optional optimization pass and the first optional codegen pass, when really it should skip the codegen pass
llvm/include/llvm/IR/OptBisect.h | ||
---|---|---|
58 | ||
83 | should probably mention that this is so that multiple pass managers don't need to coordinate their uses of OptBisect | |
llvm/lib/IR/LLVMContextImpl.cpp | ||
222–223 | ||
llvm/lib/IR/OptBisect.cpp | ||
58 | newline at end of file? | |
llvm/lib/Passes/StandardInstrumentations.cpp | ||
27 | is this include necessary? |