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

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>

Fedor Sergeev <fedor.sergeev at azul.com> 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

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 <
llvm-dev at lists.llvm.org> wrote:
> Fedor Sergeev <fedor.sergeev at azul.com> 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
> 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/20180614/80fd6a2a/attachment.html>