This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]