[llvm-dev] OptBisect implementation for new pass manager

[David Greene via llvm-dev]

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