[llvm-dev] OptBisect implementation for new pass manager

[David Greene via llvm-dev]

James Courtier-Dutton <james.dutton at gmail.com> writes:

> Q2) Take LLVM IR instruction X.
> Run pass Y once. Leaves instruction X in there.
> Run pass Y a second time should not then remove instruction X.

Do you mean multiple runs of Y back-to-back?  If so, this is a fine
requirement.  If there are intervening passes then running Y again most
certainly could make changes and remove instruction X.

I would expect if the thing constructing pass pipelines expects pass Y
to not be idempotent, it would construct the pipeline accordingly,
inserting multiple instances of pass Y itself.  Then OptBisect would
naturally eliminate the multiple instances, possibly uncovering a bug in
one of those instances.

In some ways, operation like that is desirable, as it would reduce the
number of diffs between a passing and failing run.  What is OptBisect's
role in the common way a pass is constructed?

  while (Change) {
    Change = runOnePassRound();
  }

Should OptBisect insert itself into this loop and shut off pass
operation after N iterations?  I would say no, as it seems like that
would complicate both OptBisect and the pass itself.  Once a pass is
identified as problematic, it's usually straightforward to insert things
like DebugCounters to further reduce the diffs.

> Q3) Do any LLVM IR passes do delayed instruction elimination?
> I.e.
> Pass 1 marks some instructions for removal.
> Pass 2 marks some more instructions for removal.
> Pass 3 actually removes the instructions. (the expensive bit where
> caches, indexes etc. need rebuilding)
> I only mention this Q3, because I think it could affect the way
> opt-bisect should work. (see Q1 above) Should the answer be Pass 1 or
> Pass 3 ?
>
> Is opt-bisect something that can help with these use cases?

Instruction selection works this way.  It consults metadata to decide
which instructions to pick.  It does this for non-temporal operations,
for example.

As to whether Pass 1 or Pass 3 should be disabled, it depends.  In the
isel case it must be Pass 1 that is disabled, because isel cannot be
disabled.

If Pass 1 and Pass 2 are considered transformation passes, which they
are because they are adding information to the IR, then they will be
candidates for OptBisect to disable.  So disabling any of Pass 1, Pass 2
or Pass 3 may cause the bug to go away.  This is an example where a
simple bisect is not enough.  Ideally the tool would report back that
all three passes are needed to expose the bug.  That would give a clue
to the developer where the real problem is.  But that is an enhancement
that can be added later.  It's a relatively uncommon case.

                         -David