This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC3 to GCC4 performance regression. Bug?
On Friday 25 March 2005 01:31, James E Wilson wrote:
> On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
> > I'd suggest trying -fmove-loop-invariants, and report a bug about
> > that instead if it does not move those loop invariants. We really
> > should move away from loop.c anyway.
>
> In general, yes, but we will probably always need some RTL loop
> optimizations.
I don't believe anyone has ever claimed otherwise. And my suggestion
is exactly to enable the new RTL invariant code motion pass ;-) See
loop-invariant.c.
> Lowering gimple to RTL may expose target dependent loop
> invariants that were not present in the gimple. Hence, we still need
> the RTL loop pass to work.
No, we need the *new*, CFG based RTL loop optimizers to work. They,
together with the tree loop optimizers, should subsume and improve on
all the billion-and-a-half things loop.c currently does.
> There is also the issue of the special looping branches,
If you mean doloop, see loop-doloop.c, the code in loop.c is already
gone for a long time now ;-)
> There is also the more pragmatic problem that we are suffering user
> visible performance losses right now, and we shouldn't force users to
> wait for future tree-ssa enhancements to fix them when an apparently
> relatively simple RTL optimizer change can fix them.
Unless the new loop optimizer does not fix the performance losses,
I'd disagree. We should concentrate on blowing away loop.c. It is
a tragedy we still need it. Right now, loop.c makes it impossible to
shuffle the passes in the RTL optimizer path, because loop.c destroys
the CFG and, all profile information with it. And there really is
not that much that loop.c still does. On the tree-profiling-branch
we have already disabled the old RTL loop optimizer (note *old*) and
I would be very disappointed if we can not do the same thing on the
mainline for GCC 4.1.
Gr.
Steven