[PATCH] Add FMA_EXPR, un-cse multiplications before expansion
Richard Guenther
rguenther@suse.de
Fri Oct 22 14:46:00 GMT 2010
On Fri, 22 Oct 2010, Joseph S. Myers wrote:
> On Fri, 22 Oct 2010, Richard Guenther wrote:
>
> > Out of interest, does FP_CONTRACT allow only a * b + c to be contracted
> > or also sth like a * b + c * d + e + f? Thus, is re-association
> > allowed before contraction? Does writing (a*b) + c forcefully
> > disable contraction (in the present state it would for the Fortran
> > frontend and the GIMPLE FMA generation)?
>
> My interpretation is that anything that is a floating-point source
> expression may be contracted. You could for example contract the above
> using fma(a, b, c * d) or fma(c, d, a * b), because a * b + c * d is a
> subexpression in the C syntax. If a processor had an instruction that
> computed x+y+z, rounded once, then you could contract as add3(a*b, c*d,
> e). But you couldn't contract using fma(c*d, e) as there is no c*d+e
> subexpression - you can't reassociate.
>
> Parentheses in C should always be considered purely syntactic. That is,
> (a*b)+c does not disable contraction.
>
> > I think for GIMPLE we might be able to simply wrap statement
> > RHS in a PAREN_EXPR which would disable contraction across source level
> > statements (I guess we also need to handle call results this way,
> > otherwise inlining could confuse us here). I'd say we can also
>
> Yes, I don't think you should contract mult(a, b) + c where mult() is a
> function call, even if inlined.
>
> > choose to not implement -ffp-contract=on if any of the -ffast-math
> > flags are enabled. That would make the re-association a non-concern.
>
> Indeed, I think that any of (-ffast-math, -funsafe-math-optimizations,
> -fassociative-math, -freciprocal-math) could reasonably force
> -ffp-contract=fast to be in effect - they'll all have sufficient effects
> on accuracy of results that contracting questions become irrelevant. (I
> don't think there should be any problemative interactions with other flags
> such as -ffinite-math-only or -fno-signed-zeros.)
Ok. I was suggesting that we still support -ffp-contract=off with
-ffast-math (it's easy enough to implement), just -ffp-contract=on
doesn't make much sense with any -ffast-math flags, so -ffp-contract=on
would effectively become -ffp-contract=fast.
Richard.
More information about the Gcc-patches
mailing list