[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