[llvm-dev] RFC: Pass Execution Instrumentation interface

[Fedor Sergeev via llvm-dev]

On 06/13/2018 07:46 PM, David A. Greene wrote:
> 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.
I would rather not merge pass-execution and in-pass-transformation 
numbers into a single number.
It will only confuse users on what is being controlled.
Especially as in-pass control is going to be opt-in only.

>
>
>>> 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
As Philip has already pointed out, analyses by design are expected to be 
non-mutating.

regards,
   Fedor.

> 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