I see a 50% cycle increase for EEMBC idctrn01 going from gcc 4.2.1 to gcc 4.4 .
There are two issues, overzealous unrolling, and constant propagation in the
unrolled loops.
While both issues can be avoided by reducing the parameter
"max-completely-peeled-insns" to 200, this is not really satisfactory, since
that is a rather fragile parameter setting and is not really related to the
problem, and it holds other code back, like EEMBC viterb00 benchmark, which
looses 5% performance with that setting.

There are a number of loops which are completely unrolled,
thus pushing their containing loop size above the size of the instruction
cache.  There is no point in doing such unrolling, since it is more expensive
to fill the instruction cache with an unrolled loop than to execute a rolled loop.
I have implemented a heuristic to estimate the size of the outer loop (or
function in absence of an outer loop) assuming that its inner loops will be
unrolled in accordance with PARAM_MAX_UNROLL_TIMES, PARAM_MAX_UNROLLED_INSNS
and PARAM_MAX_COMPLETELY_PEEL_TIMES, and if that size exceeds a threshold
(a new parameter), complete unrolling is inhibited.

This change has reduced the idctrn01 regression to 13.7% while leaving the
other EEMBC benchmarks alone.
I expect that I can address the remaining performance regression by
inhibiting inappropriate constant propagation - there are 798 addresses
of the form absolute address+offset in the main benchmark assembly file,
each of which translates into one instruction word too many, in total
20% of the text size of that module.

I can post the unroller heuristic patch as soon as we have the confirmation
from the FSF that they have filed the Copyright Assignment we gave them
last year.