Problem with -ftree-ter and loop unrolling

Steven Bosscher stevenb@suse.de
Wed May 18 13:43:00 GMT 2005


On May 18, 2005 03:06 PM, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:

> So far OK, but with ter, this becomes
> 
> sum1 = 0;
> sum2 = 0;
> for (i = 0; i < n; i+=4)
>   {
>     x_1 = a[i];
>     y_1 = b[i];
>     x_2 = a[i+1];
>     y_2 = b[i+1];
>     x_3 = a[i+2];
>     y_3 = b[i+2];
>     x_4 = a[i+3];
>     y_4 = b[i+3];
>     sum1 += x_1 * y_1 + x_2 * y_2 + x_3 * y_3 + x_4 * y_4;
>     sum2 += x_1 / y_1 + x_2 / y_2 + x_3 / y_3 + x_4 / y_4;
>   }
> 
> Now we need some 11 registers for the loop, instead of the original 5
> (and the number of registers grows with the unroll factor).

The TER hack we settled on for PR17549 was supposed to prevent this kind
of thing, but it was already obvious at the time that a better fix is
needed in the general case.  You've find a pretty nasty one here.

> This causes huge regressions (more than 60% on sixtrack from spec2000).
> It might perhaps be a good idea to limit the size of expressions ter
> produces, or in some other way restrict the way it increases the lives
> of registers?

/me pretends to be surprised ;-)

There is really no easy measure for register pressure in tree-outof-ssa,
so fixing this may be hard.  Perhaps we should disallow TER to combine
things across loads, or limit the maximum number of expressions it is
allowed to combine...

Gr.
Steven





More information about the Gcc mailing list