When profile based feedback indicates that a loop has a low iteration count, it will often refuse to unroll even though unrolling is still useful. Moreover, while it knows about the average loop iteration count, it lacks the concept of a prevalent iteration count. In particular, the header checksumming of the EEMBC packetflow benchmark usually has ten iterations. With gcc 3.x, unrolling was by a factor of four, which was mediocre. With the introduction of the new loop unroller in 4.0, unrolling when doing profile feedback was no longer done at all. The proper thing to do would be to unroll this loop five times. When the case of a loop that is not a multiple of the chosen unroll factor is deemed sufficiently unlikely, that case can be taken care of by generating a non-unrolled loop after the unrolled loop. The unrolled loop can use a suitably transformed unequality check for the loop start and end to verify that a sufficient number of iterations is outstanding, so that no casesi / tablejump code is needed. See also: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02373.html
> With the introduction of the new loop unroller in 4.0, I think you mean 3.4.0 because the new unroller was in 3.4.0.
(In reply to comment #1) > > With the introduction of the new loop unroller in 4.0, > I think you mean 3.4.0 because the new unroller was in 3.4.0. > You're right, it was introduced then. Although the old loop unroller was still present in 3.4.0 and could be selected with a flag - which was useful to get avoid performance regressions.
Old bug without test case => closed