[PATCH] D104551: Delay initialization of OptBisect
Andy Kaylor via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 29 18:11:13 PDT 2021
andrew.w.kaylor added a comment.
In D104551#2909024 <https://reviews.llvm.org/D104551#2909024>, @kparzysz wrote:
> Yes, that's exactly what happens. The project uses LLVM as a code generator for multiple targets. The `OptBisector` object is constructed the first time it's queried by `shouldRunPass`, which happened during the code generation for the first target. We set up the second target by passing some extra flags to `ParseCommandLineOptions`, but passing `-opt-bisect-limit` at this time no longer has any effect (i.e. the setting from the construction time remains).
That case is more complex than opt-bisect was originally designed for, but I guess if you have a way to independently specify the bisect limit for each target, you should be able to make it work. To make the implementation more general, I'd suggest that the CurBisectNum should be reset between the targets and probably any time the limit is changed.
Replacing the default OptBisect with a custom OptGate might be a better solution. That said, I wouldn't be opposed to your current change as a quick and possibly temporary solution if you add something to reset the counter.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104551/new/
https://reviews.llvm.org/D104551
More information about the llvm-commits
mailing list