[llvm-dev] OptBisect implementation for new pass manager

[Kaylor, Andrew via llvm-dev]

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