[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

On 10/01/2018 08:39 PM, David Greene wrote:
> "Kaylor, Andrew" <andrew.kaylor at intel.com> writes:
>
>> What if in the registration interface we had three options: skippable,
>> not skippable, and run at OptLevel::None.
> I kind of like this idea.  If necessary, the pass could even query the
> target (or some other entity) about what OptLevel::None means.
>
> If we have such query hooks, do we need "not skippable?"  If a pass is
> not skippable, then running at OptLevel::None should be fine, as long as
> the pass can know what it needs to do at OptLevel::None (at minimum
> produce functional code).
>
> "Not skippable" seems to imply "run the pass at full(-ish) optimization
> always."  Maybe that's a useful third state, I'm not sure.
Seems like our current vocabulary is somewhat imprecise.

I'm not sure that I fully gather which part of pipeline 
construction/execution and which
object interaction do you mean when talking about "query hooks" or "run 
the pass".

Right now we have the following objects:
    - OptBisect, which is pass-instrumentation object
    - PassBuilder object that constructs the pipeline
    - PassManager object that controls the pass execution
    - Pass object, which is being constructed for PassBuilder and then 
executed with PassManager

At construction time there are:
   Pass, OptBisect, PassBuilder objects
and at execution time there are:
   Pass, OptBisect, PassManager objects
which of those do you see interacting when you talk about "query hooks"?

My mental model of "not skippable" handling:
   - OptBisect is the controlling object.
   - at construction time it tracks objects being constructed and stores 
its "skippable"/"unskippable" properties.
   - at run-time PassManager asks OptBisect and it reports whether to 
skip the pass or not.
     PassManager acts accordingly.

"run the pass at full optimization" is something that I dont see a clear 
mental model of.
Obviously it is the Pass itself that can run itself at full optimization 
*if* it gets control.
PassManager can pass the control to the Pass.
OptBisect does not run at all, it just advises the PassManager.
How Pass decides that it runs at full optimization/half optimization?

(side note - it appears that for any kind of interaction we first should 
design the execution part of it,
and only then go for the construction time)

regards,
   Fedor.