Re: [PATCH][dbgcnt] New debug counter global_alloc_at_func, global_alloc_at_reg, and make sched_insn work

[Ayal Zaks <ZAKS at il dot ibm dot com>]

$)C"Seongbae Park (9Z<:9h, ZS`w[F)" <seongbae.park@gmail.com> wrote on
27/06/2007 17:50:08:

> On 6/27/07, Ayal Zaks <ZAKS@il.ibm.com> wrote:
> >
> > We should use dbg_cnt instead of MAX_SMS_LOOP_NUMBER in modulo-sched.c.
>
> Probably, as debug counter provides slightly better abstraction.
> Ultimately we should be able to write a script that does the binary
search
> using various counters automatically, even a script that finds
> the correct counter to use. One option I haven't implemented
> is to dump the counters at the end of the compilation
> - this in itself is interesting as we can see how many times
> each counter is triggered, but it's actually very useful
> because we can use those values as the upper bound for the binary search.
>

Yup.

> > Perhaps these counters should be part of every pass, and use the
inherent
> > pass names. In some cases a pass may want more than one counter.
>
> I haven't put a lot of thought into naming convention for the counters,
> I'm sure having some convention would be nice - any idea ?

The thought was to incorporate these counters into tree_opt_pass, thereby
promoting their usage by every pass similar to that of timevar or
dump_file. And to use the pass name/number/letter or the flag names that
turn passes on/off, to construct the counter names.

> Most likely, those counters have different granularity -
> function/block/instruction/
> transformation/register/ or whatever the unit of each optimization.
> The finer control we have, the better.
>
> > Are there
> > any optimizations that cannot make use of such a counter?
>
> I'm sure there are. But once we have enough passes
> that have the finer control, even passes that can't have such a counter
> will benefit, as long as we can control passes before the problematic one
> to trigger/not trigger the buggy condition.

Agreed.
Ayal.

> --
> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";