[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

On 10/01/2018 11:13 PM, David Greene wrote:
> Philip Pfaffe <philip.pfaffe at gmail.com> writes:
>> Sorry, but I strongly oppose to the road you're suggesting here. As I
>> said before the Pass*Manager* is entirely the wrong place to handle
>> OptNone, the absolutely the wrong design. It makes sense for function
>> *only*, and immediately breaks down everywhere else. Frankly, OptNone
>> should take no role in this particular discussion, and I feel like so
>> far it has because "We've always done it this way".
> I think we're miscommunicating.  I'm not talking about the optnone
> function attribute and I don't think Andy is either.  I'm saying that
> one option for "skipping" passes that must run is to run them in a
> degraded mode where they do just enough to generate functional code.
> One way (though maybe not the best way) is to tell the pass to run that
> way via the OptLevel::None value.
We better use "pass execution" terminology rather than "optimization 
level" one.
Lets say that pass "runs in 'skip' mode".

> Even Module passes could run in degraded mode.
>> Second, I don't completely subscribe to the arguments towards
>> not-skippable passes. Fundamentally: Who decides whether a pass is
>> skippable or not? _When_ is a pass skippable, when isn't it? Neither
>> the Pass nor the PassManager may actually decide that. The only things
>> that do are the pipeline builder and the bisecter. Pipeline builder
>> here means the driver tool that constructs and executes the pipeline
>> (like clang or opt), not PassBuilder. We can achieve that if we put
>> this feature into the instrumentation instead. Here we have the right
>> amount of control, at least cost and minimal complexity. Then, all we
>> need to is get the default treatment right. If we can agree on whether
>> we truly want to not skip some passes 90% of the time, than we can
>> just encode that as an overrideable default, such as by tracking a
>> list of non-skippable passes right there in the implementation.
> I think that's compeletely fine.  You're right that neither the pass
> manager nor the pass can make those decisions.
Yes, I believe we can state that OptBisect (and OptBisect only) makes 
those decisions.
>    The piece I don't yet
> grasp is how we express that a pass is not skippable (or may be run in
> degraded mode) in various contexts.  How do we provide the information
> so that pass instrumentation may make the correct decision?
As Philip already mentioned, "by tracking a list of non-skippable passes 
right there
in the implementation"   .... of OptBisect, I assume.
> I do think running a "must run" pass in degraded mode during bisecting
> is very useful.
And that is the most tricky part - how does pass know that a particular 
pass *invocation*
runs in 'skip' mode?

It appears that the only "proper" way for passes to get "outside" 
information is to ask for the analysis.
So we need special analysis deployed by OptBisect object that tells 
those tricky passes like
scheduler that they need to run in 'skip' mode.

regards,
   FEdor.

>
>                               -David