This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Instrument alias oracle
On Fri, 6 Feb 2009, Richard Guenther wrote:
> 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.
After some chatting with Michael we came to the conclusion that it
doesn't make sense to use timevars here in general.
All alias-oracle operations (apart from the walk_non_aliased_vuses one)
are of linear complexity, so counting invocations is enough and
makes much more sense.
So I will add a basic counting that is always-on instead of using
timevars for the various entry-points.
Does that sound ok?
Thanks,
Richard.