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

Reply via email to