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: fix opt/8634


> Hello,
> 
> > > I believe purge_addressof costs us almost nothing (I cannot be sure,
> > > as it has no timevar, but the fact that nobody bothered to add one
> > > tells something); is this really the right place where to attempt to
> > > save?
> > 
> > It's got to be about the same cost as purge_builtin_constant_p,
> > as both involve one linear scan of the insn stream.  Which was
> > identified as a definite regression in gcse times, which led to
> > a sequence of patches that avoided running it whenever possible.
> > 
> > If you added a timevar, you'd notice that you've just about
> > exactly doubled the amount of time spent here.
> 
> OK; then it seems that there is something rotten in the very heart of
> gcc.  How can it not be slow when just a simple pass over insns takes
> a non-trivial time?

Not too rotten - GCC does some mostly fixed amount of passes over RTL
and there are not that many of them.  Assuming that they are 50 of them,
one should cost about 2%.  Sure some are slowers than the others but in
majority cases we are really limited by memory bandwidth.

As I've mentioned earlier, I am still thinking about reorganizing the
100% local passes (like purge_addresssof is I believe) into callbacks
for given insn so we can do multiple of them in the parallel - like
second addressof pass together with reg-scan update.  Not sure how much
that would help and how dificult it can be to maintain tought, so I am
not at all sure it is good idea...

Honza
> 
> Zdenek


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