There was some discussion on the GCC mailing list in late August, early September about a performance regression caused by the disabling of the old loop optimizer when doing FDO. http://gcc.gnu.org/ml/gcc/2005-08/msg00899.html Loop invariant motions done by the old loop optimizer no longer occur. This is causing a performance regression on some benchmarks. The following patch enables loop invariant motions during FDO and fixes the observed performance regression: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00224.html
Confirmed.
Linking to the testcase for future reference: http://gcc.gnu.org/ml/gcc/2005-08/msg00910.html
Leaving as P2.
We have the following two options: - Make loop.c preserve the profile. We all know that's not doable. - Backport the loop-invariant.c changes from the killloop-branch and enable -fmove-loop-invariants when doing FDO. We should not do this because loop-invariant.c has not seen enough testing yet. So IMHO this is not fixable for GCC 4.1.
Created attachment 10170 [details] merge patch from the killloop-branch With this patch applied and -fmove-loop-invariants enabled by default at -O2, I am getting regressions in libjava on ia64. But it does bootstrap there and also passes bootstrap&testing on i686, x86_64, ppc, and ppc64 without problems.
I found an extra problem with loop-invariant.c, which is that it would move expressions out of loops with calls, even if the expressions used call clobbered hard registers. I'm testing a fix for this bug now, too...
This will *NOT* be fixed for GCC 4.1.
Fixed in GCC 4.2 now that -fmove-loop-invariants is enabled by default. Closing as WONTFIX because this is really not fixable for GCC 4.1. without major surgery or ugly and unsafe hacks.