[llvm-dev] RFC: Pass Execution Instrumentation interface

[David A. Greene via llvm-dev]

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

>> 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.

Oh, ok.  I'm fine with that too.  Do we want this finer-grained control
on a global basis, or a per-pass basis?  For example, should something
like -transform-max=<n> apply over the whole compilation run, so that
every pass checks the limit, or should it work like
-transform-max=<pass>=<n>, where only pass <pass> checks the limit?  If
the latter, then -opt-bisect-limit (or bugpoint) can identify the pass
and another run with -transform-max can identify the specific transform
within the pass.

The latter is how we have things set up here and it seems to work well,
but I can also see utility in a global limit because then you don't need
two separate runs to isolate the problem.

I'd like to start building this off the pass instrumentation stuff as
soon as it gets integrated.  Could you copy me on Phabricator when they
land there?  Thanks!

>> 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.

See my reply to Philip.  I'm talking about various analyses that happen
within transformation passes.

                               -David