[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

On 10/02/2018 01:17 AM, Kaylor, Andrew wrote:
> Some of the issues we're talking about were also considered when I did the initial implementation of OptBisect. If anyone wants to look at the relevant reviews they can be found here:
Thanks for sharing these, very useful!
> https://reviews.llvm.org/D18576 (Abandoned first attempt)
> https://reviews.llvm.org/D19172 (Committed second version)
>
> Then there were a dozen or so revisions to implement the opt-in process.
>
> The highlights were:
>
> - My initial implementation had a hard-coded list of passes that couldn't be skipped. We agreed that was awful.
> - Paul Robinson mentioned that during the initial work on the "optnone" attribute they want a way for each pass to identify itself as skippable or not and the pass manager would only run non-skippable passes on an "optnone" function. He said, "Chandler was adamant that we NOT do it this way, that the pass manager should remain ignorant of this sort of trickery and each individual pass would need to decide for itself whether 'optnone' was something to pay attention to." This led to the current implementation where "optnone" and opt-bisect are both handled in the passes' run functions.
If I interpret Chandler right, generic nature of pass instrumentation 
framework solves this objection by abstracting everything out of pass 
manager itself.
There is now a good alternative to both coding everything in all the 
passes and polluting pass manager with non-pass-managing details.

regards,
   Fedor.

> - At one point I had something (mostly?) working with the new pass manager, but it broke with Address Sanitizer and since the new pass manager wasn't ready to go then we decided to strip that part out completely.
>
> -Andy
>
>