llvm dev - Oct 2018 - OptBisect implementation for new pass manager

What if in the registration interface we had three options: skippable, not
skippable, and run at OptLevel::None.

We'd need some way to communicate the OptLevel::None to the pass, but that
doesn't seem terrible.

-Andy

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

Fedor Sergeev <fedor.sergeev at azul.com> writes:
>     I don’t have strong feelings about how this happens. Off the cuff,
>     it could be added to the pass registration information or it could
>     be a function provided by the pass, preferably through one of the
>     mixins so that pass developers don’t need to think about it.
>
> I'm leaning towards the registration-time activities, which perhaps 
> means doing extra interaction between PassBuilder and OptBisect.
> As we seem to favor the opt-out (and for current - non-CodeGen - 
> implementation the out-out list appears to be empty? ) exact mechanism 
> of that out-out does not really bother me.
I think registration time is probably fine for IR/opt-level passes.  For codegen
it will probably work 95% of the time but there are some cases where we may not
know at registration time whether the pass is needed or not.  I'm making the
assumption that registration happens basically as it does now, where the
registration logic is baked into the compiler source and there is no good way to
pass runtime information (such as the
target) during pass registration.

I brought up scheduling before.  For most targets, scheduling is purely an
optimization.  If it doesn't run it won't affect correctness.  But for
some targets, it (theoretically) will.  I'm thinking of targets like VLIW
machines, targets with branch delay slots, targets without hardware pipeline
interlocks and so forth.

Now, it may be that such targets take a very conservative approach during isel,
so as to guarantee functional correctness even without scheduling.  In that case
it's fine to not run the scheduler.  But that means such targets have to be
aware of OptBisect at a deep level -- they need to design their isel in an
OptBisect-friendly way.

This is why I said earlier that the entity that understands these properties
lives above passes, pass managers and OptBisect.  The thing constructing the
pass pipeline has all the knowledge.  Whatever piece of code calls
PassManagerBuilder methods or TargetPassConfig methods.
Possibly things like X86PassConfig have all the information for codegen passes. 
This is one of the reasons I think the codegen pass pipeline stuff is a little
wonky -- it works very differently from the higher-level pass pipeline
construction.

We should also be aware of how this will work in the presence of multiple
targets (CPUs and GPUs for example).  OptBisect will eventually need to
understand that a pass might be fine to disable on one target but not another,
within the same compilation process.

I'm not saying we need to solve these problems now, just that we need to be
aware of them.  It won't affect the vast majority of targets but for those
targets where it matters, it could be ugly.  If it's ugly but still works,
I'm totally fine with that.  Make it nice for the common case and possible
for the uncommon case.

                             -David

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

                         -David

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.