[llvm-dev] RFC: Pass Execution Instrumentation interface

[Fedor Sergeev via llvm-dev]

On 06/13/2018 09:13 PM, Philip Pfaffe wrote:
> On Wed, Jun 13, 2018 at 8:03 PM David A. Greene via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Fedor Sergeev <fedor.sergeev at azul.com
>     <mailto: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.
My problem with debug counters is that they are ... well ... debug-only :)
I was planning to use debug counters for the purpose of pass execution 
counting but then
realized that it will not work in Release mode at all.

But other than that debug counters seems to be a exactly a machinery 
designed for opt-in control of internal pass activity.

regards,
   Fedor.

>
>     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 <mailto: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/6a615022/attachment.html>