RFC: Pass Execution Instrumentation interface

Philip Pfaffe <philip.pfaffe@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

My problem with debug counters is that they are … well … debug-only :slight_smile: 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.

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

My problem with debug counters is that they are ... well ...
debug-only :slight_smile:
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

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 :slight_smile:

George Burgess IV <george.burgess.iv@gmail.com> 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` :slight_smile:

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

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