[llvm-dev] RFC: Pass Execution Instrumentation interface

[Philip Pfaffe via llvm-dev]

On Wed, Jun 13, 2018 at 8:03 PM David A. Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
This seems to be pretty much orthogonal to the pass manager
instrumentation. In fact, there is nothing keeping you from implementing
this for your pass right now using debug counters. That's mostly their job,
and they are independent of the pass manager implementation.

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.

I see, then I just misunderstood what you meant by analysis. I believe what
you were going here for can as well be implemented on top of debug counters.


Cheers,
Philip




>
>
                               -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180613/eb55831a/attachment.html>