[llvm-dev] OptBisect implementation for new pass manager

David Greene via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 12:14:56 PDT 2018


Fedor Sergeev <fedor.sergeev at azul.com> writes:

>>   What happens if a transformation pass depends on another
>> transformation pass earlier in the pipeline?  If the earlier
>> transformation pass is bisected out, then...???
> If we talk about current bisection scheme then the only passes that
> are run after the bisection point are those required-to-run passes.
> And that means required passes should not depend on anything else than
> other required passes. Which seems to be a very reasonable restriction
> to me.

Let's say opt-bisect is opt-in.  Then the pass does something like this:

if (ShouldRun(Me)) {
  ...
}

return;

Let's say pass A and B both opt-in.  Pass B depends on pass A.  If Pass
A is bisected out, then even though B depends on it and the PassManager
will think it's running pass A, pass A won't actually do anything.  Pass
A doesn't know whether it's being run due to a dependency or not.

If opt-bisect is opt-out (so passes don't do anything to participate in
bisection), then in theory the PassManager will run pass A because B
needs it.  But the bisect mechanism will have to get out of the way to
fulfill the dependency.  This also potentially changes the order passes
run, which could lead to real trouble.

So pass A needs to opt out of opt-bisect.  But someone has to know that
something depends on pass A in order to have pass A opt-out (or not
opt-in).

Therefore, it seems like opt-in is safer but unfortunately that makes
for a worse debugging experience.

Now, one could argue that perhaps pass B shouldn't be so strict and have
a dependency on pass A.  But it exists today in codegen and maybe other
places.

                       -David


More information about the llvm-dev mailing list