PR43902 patch: Widening multiply-accumulate

Richard Guenther richard.guenther@gmail.com
Wed Jun 23 12:43:00 GMT 2010


On Wed, Jun 23, 2010 at 2:16 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 23 Jun 2010, Paolo Bonzini wrote:
>
>> On 06/23/2010 01:38 PM, Joseph S. Myers wrote:
>> > On Wed, 23 Jun 2010, Richard Guenther wrote:
>> >
>> > > PAREN_EXPR is supposed to act as re-association barrier only.
>> > > So techincally for t = a*b; f = t+c; we could emit t = (a*b); f = (t+c);
>> > > so the middle-end would see ((a*b)+c) which we could avoid to
>> > > contract based on the parens.
>> >
>> > I'd expect that f = a*b+c; would be expanded to exactly the same t =
>> > (a*b); f = (t+c); GIMPLE, given that no reassociation is permitted in C99;
>> > certainly f=a*b*c; would be expanded in a way that reflects that this is
>> > (a*b)*c and no reassociation is permitted.
>>
>> With FP_CONTRACT on, you would expand it as t1=a*b;t2=t1+c;f=(t2).
>
> This certainly sounds much like the front end having knowledge of the
> particular contracted operations that are available on the target, so as
> not to insert PAREN_EXPR about (a*b).  Or are you saying that in the
> absence of -fassociative-math, PAREN_EXPR would operate as a barrier to
> contraction but that reassociation wouldn't be permitted at all, so that a
> single PAREN_EXPR would go around each maximal source expression within
> which contraction is permitted and that (a*b*c+d) could then be evaluated
> as a fused operation on a*b, c and d but not one on a, b*c and d?

PAREN_EXPR is always a re-association barrier, even with
-fassociative-math.  Without -fassociative-math _all_ reassociation
is prohibited.  So yes, you'd place a PAREN_EXPR around each
maximal source expression to limit contraction.

Richard.

> --
> Joseph S. Myers
> joseph@codesourcery.com
>



More information about the Gcc-patches mailing list