[llvm-dev] RFC: Pass Execution Instrumentation interface

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 14 12:33:30 PDT 2018

(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 <
llvm-dev at lists.llvm.org> wrote:

> George Burgess IV <george.burgess.iv at 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` :)
> 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
> 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/20180615/9098ee99/attachment.html>

More information about the llvm-dev mailing list