This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR43902 patch: Widening multiply-accumulate
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?
--
Joseph S. Myers
joseph@codesourcery.com