Re: [rtl-optimization] Improve Data Prefetch for IA-64

[James E Wilson <wilson at specifixinc dot com>]

Steven Bosscher wrote:
> OK, so I know this is not a popular subject, but can we *please* stop
> working on loop.c and focus on getting the new RTL and tree loop passes
> to do what we want?

I don't think anyone is objecting to this.  My answers in an earlier 
thread were a little confused because I didn't realize you were talking 
about the new RTL loop optimizer.  I thought you were talking about the 
tree loop optimizers.  I forgot the new RTL loop optimizer was there.  I 
was only arguing for the existance of any RTL loop optimizer, of which 
the new RTL loop optimizer certainly qualifies.

I would however make a distinction here between new development work and 
maintenance.  It would be better if new development work happened in the 
new loop optimizer.  However, we still need to do maintenance work in 
loop.c.  If gcc-4 suffers a performance regression because of a bug in 
loop.c, then that bug should be fixed.  That is why I was arguing for a 
loop.c bug fix in an earlier thread.  Not to make loop.c better.  Only 
to make loop.c work as well as it did in gcc-3.4, until such time that 
it can be replaced.

> reason why there is no profile information available before this old
> piece of, if I may say, junk runs, and it the only reason why a great
> many functions in for example jump.c and the various cfg*.c files can
> still not be removed.

"outdated" is a better term than "junk".  loop.c was written in a 
different era, under very different circumstances, and is rather good 
given the constraints of the time.  It has served us well for a long 
time, but has now outlived its usefulness.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com