[llvm-dev] OptBisect implementation for new pass manager

David Greene via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 10:13:22 PDT 2018


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

>         - what would be preferable - opt-in or opt-out?
>
>         - with legacy implementation passes opt-in both for bisect and
> attribute-optnone support at once.
>           Do we need to follow that in new-pm implementation?
>
> Also, I would like to ask whether people see current user interface
> for opt-bisect limiting?

Ideally I would prefer an opt-out model.  Practiclaly speaking, I'm not
sure that's possible.  Presumably opt-bisect doesn't apply to analysis
passes.  What happens if a transformation pass depends on another
transformation pass earlier in the pipeline?  If the earlier
transformation pass is bisected out, then...???

It seems to me that optnone and opt-bisect are two different things and
therefore they should be handled orthogonally.

As for the user interface:

It might be nice to have opt-bisect skip/count capability similar to
DebugCounters.  But even that might not be enough.  Often a bug requires
some subset of transformations to run.  For example, if the pipeline is:

A->B->C->D->E

I might need B, D and E to run to see the bug (A and C don't matter).
If I understand things correctly, today opt-bisect would report that all
of A-E need to run to manifest the bug.  That's usually plenty good
enough as running and not running E may result in a small enough set of
diffs to be workable.  But it may be that running B->D->E and B->D
results in a smaller number of diffs.  Skip/count would get us to
B->C->D->E and even that might be an improvement.

I don't see this as a day-one requirement for the new opt-bisect, but
rather a longer-term goal to improve debugging precision.

How does all of this relate to bugpoint?  AFAIK bugpoint doesn't use
opt-bisect at all.  It can arrive at the B->D->E minimal pipeline.  It
seems worthwhile to put some effort into unifying capabilities and
sharing code.  bugpoint is a bit of a mess, unfortunately.  It would be
great to modernize it and make use of new internal debugging
capabilities that didn't exist when it was created.  Maybe that's a
project that could start after the new PM becomes default and the new
opt-bisect is in place.

                          -David


More information about the llvm-dev mailing list