Re: [PATCH] Add FMA_EXPR, un-cse multiplications before expansion

[Richard Guenther <rguenther at suse dot de>]

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.