llvm dev - Jun 2018 - RFC: Pass Execution Instrumentation interface

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

"David A. Greene via llvm-dev" <llvm-dev at lists.llvm.org>
writes:
> 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!
BTW, I am "greened" on Phabricator.

                             -David

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>

Philip Pfaffe <philip.pfaffe at gmail.com> writes:
> 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.
Yes, it sounds like that will work.  When I did things on our end, those
didn't exist.
>     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.
I don't think anything is needed other than debug counters, if I'm
understanding how they work.  If we wanted some kind of global limit
that would require more, but we haven't found a need for that.

Thanks for the pointer!

                            -David

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>