[llvm-dev] RFC: Pass Execution Instrumentation interface

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
Philip Pfaffe <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
In reply to this post by Jonathan Wakely 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 <[hidden email]> wrote:
Fedor Sergeev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
Fedor Sergeev <[hidden email]> writes:

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

Why were debug counters made debug-only in the first place?  We
certainly use our -pass-max stuff in release builds.  Most of the time a
debug build is fine but for some codes a debug build is way too slow to
allow bisecting in a reasonable amount of time.

                              -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
FWIW, I was able to use the EarlyCSE debug counters without issue in a Release build with -DLLVM_ENABLE_ASSERTIONS=Yes. Further, the only preprocessor checks I see around debug counters use `NDEBUG`. Am I missing something?

It seems reasonable to me to require that assertions are on when you're trying to debug the compiler. Not so much to require that the compiler itself has been built with `-O0` :)

On Wed, Jun 13, 2018 at 1:44 PM David A. Greene via llvm-dev <[hidden email]> wrote:
Fedor Sergeev <[hidden email]> writes:

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

Why were debug counters made debug-only in the first place?  We
certainly use our -pass-max stuff in release builds.  Most of the time a
debug build is fine but for some codes a debug build is way too slow to
allow bisecting in a reasonable amount of time.

                              -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
George Burgess IV <[hidden email]> writes:

> It seems reasonable to me to require that assertions are on when you're
> trying to debug the compiler. Not so much to require that the compiler
> itself has been built with `-O0` :)

Thanks for explaining things.  It's a little weird, name-wise, to use
ENABLE_ASSERTIONS to get debug counters but I can see how it would make
sense.

                              -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] RFC: Pass Execution Instrumentation interface

Jonathan Wakely via llvm-dev
(apologies if you get this twice -- airplane internet isn't much good)

I mostly want to make two high level points:

1) I agree w/ George that relying on assertions to enable debug counters seems acceptable. I understand that the name isn't ... super obvious. But on the flip side, they should only used for debugging the compiler, not for functionality, and in that sense the name makes sense and erasing them when assertions are disabled also makes sense.

2) I'd really suggest not trying to couple fine grained (in-pass) debug counters with opt-bisect like functionality of pass bisection. I think those are best represented with independent counters. Layers on top of this can move between them for bisection if useful, but I think conflating them would add complexity. I especially think it is useful to first get the basic pass bisection in place for the new PM rather than trying to buildng something new and more fancy. That said, I'm very happy if they still are using the shared debug counters infrastructure.

On Thu, Jun 14, 2018 at 9:23 PM David A. Greene via llvm-dev <[hidden email]> wrote:
George Burgess IV <[hidden email]> writes:

> It seems reasonable to me to require that assertions are on when you're
> trying to debug the compiler. Not so much to require that the compiler
> itself has been built with `-O0` :)

Thanks for explaining things.  It's a little weird, name-wise, to use
ENABLE_ASSERTIONS to get debug counters but I can see how it would make
sense.

                              -David
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
12