[PATCH][RFC] Instrument alias oracle

Richard Guenther rguenther@suse.de
Fri Feb 6 15:21:00 GMT 2009


On Fri, 6 Feb 2009, Diego Novillo wrote:

> On Fri, Feb 6, 2009 at 09:16, Richard Guenther <rguenther@suse.de> wrote:
> 
> > As a different but iteresting instrumentation kind the patch
> > instruments all different disambiguations in refs_may_alias_p
> > with statistic counters, only bailing out on must-aliases but
> > continuing to count other disambiguators even if a previous
> > one said no-alias.  This allows telling apart the most effective
> > disambiguators and may help sorting them.  This instrumentation
> > is costly as well, and somehow even makes the code more ugly.
> 
> Well, it's not pretty, but with adequate commentary in the macros it's
> not too bad.  I think it will provide useful information, so I'm
> willing to put up with the macro hackery.

Ok.  The macro stuff will be off by default.

> > So - do we just want to attribute all alias-oracle time to
> > a single timevar?  Which also uglifies code as you have to
> > pop the timevar on every function exit, like for example if
> > one would push at the entry of refs_may_alias_p.
> 
> I was thinking of having a set of timers for each of the most popular
> external entry points.  If the API is very wide, then simply have a
> set of 5 timers (to pick a random smallish number) and put those
> timers at the entry points of the 5 most popular entry points.

Ok.  I guess once you enable -ftime-report the actual reported
time will be way off though, as the cost for timevar_push/timevar_pop
is much higher than the query itself most of the time.  Maybe it
is acceptable to reduce the overhead and do not stop accounting
to the caller?  Thus, use timevar_start/timevar_stop instead of
timevar_push/timevar_pop?  Of course it gets tricky with the
predicates calling each other.

Richard.



More information about the Gcc-patches mailing list