[llvm-dev] RFC: Pass Execution Instrumentation interface

[David A. Greene via llvm-dev]

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

> On 06/12/2018 12:04 AM, David A. Greene wrote:
>> // PIA - PassInstrumentationAnalysis
>> if (PIA->skipTransformation()) {
>>    return;
>> }
>> // Do it.
>> PIA->didTransformation();

> That should be easily doable (though the interface would be part of
> PassInstrumentation
> rather than PassInstrumentationAnalysis).

Ok.  The way I envision this working from a user standpoint is
-opt-bisect-limit <n> would mean "n applications of code
transformation." where "code transformation" could mean an entire pass
run or individual transforms within a pass.  Each pass would decide what
it supports.


>> This kind of interface also encourages good pass design like doing all
>> the analysis for a transformation before actually doing the
>> transformation.  Some passes mix analysis with transformation and those
>> are much harder to instrument to support -pass-max operation.

> I'm not sure everybody would agree on this definition of a good pass
> design :)
> Ability to mix analysis with transformation might appear to be rather useful
> when heavy analysis is only needed in a very special corner case of an
> overall
> transformation.

Yes, I'm sure there are exceptions.  I'm not referring to things like
instcombine that have individual rules that guard transformations and
the pass iterates applying transformations when rules are matched.
That's straightforward to instrument.

The harder cases are where the analysis phase itself does some
transformation (possily to facilitate analysis) and then decides the
larger-goal transformation is not viable.  If the pass then tries to
undo the first transformation, it's possible that -pass-max will result
in code that never would have been generated, because it could do the
first transformation but then not undo it because it hit the max number
of transforms.  Sometimes it's difficult to find where things are undone
and update the transformation index (basically allow the undo and
decrement the index to reflect the undo).

In code:

if (not hit max)
  do anlysis transform
  ++index

return

<some other function>

if (transform legal)
  if (not hit max)
    do big transform
    ++index

return

<some third function>
if (need to undo analysis transform)
  if (not hit max)
    undo it
    ++index

Sometimes it is not obvious that these three places are logically
connected.  Ideally we wouldn't increment the index for the analysis
transform or we would allow the undo and decrement the index, but it's
not always clear from the code that that is what should happen.

                            -David