[llvm-dev] OptBisect implementation for new pass manager

[Kaylor, Andrew via llvm-dev]

> 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.

That may well be the case. I certainly wouldn't want to speak for Chandler, and I have to admit the comment I made earlier sounds dangerously like a game of telephone with all the misunderstandings inherent in that.  My understanding at the time was that not having the Pass Manager make any decision based on the contents of the IR was an important part of the issue. I think you have that covered.

From there, I would argue that it's a matter of extending this sort of principle through and making sure that at each level the component involved is doing what it should be doing and not borrowing any part of another component's domain. I think we're all in agreement about that too.

At this point it feels to me kind of like we're getting a bit of churn. Concerns have been raised and discussed in circles. It doesn't seem like new concerns are coming up. Maybe you could now take this input and put together a concrete proposal for the parts that can be implemented now. I like what you've done so far and am confident that you're going in the right direction.

-Andy

-----Original Message-----
From: Fedor Sergeev [mailto:fedor.sergeev at azul.com] 
Sent: Monday, October 01, 2018 4:42 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>; David Greene <dag at cray.com>; Philip Pfaffe <philip.pfaffe at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Chandler Carruth <chandlerc at gmail.com>
Subject: Re: [llvm-dev] OptBisect implementation for new pass manager

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
>
>