This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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