On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> 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



Reply via email to