Re: PR43902 patch: Widening multiply-accumulate

[Paolo Bonzini <bonzini at gnu dot org>]

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).

> > -fcontracting-math and/or -fexpanding-math
> > (covering x*x*x*x -> t = x*x; t*t and pow(x,4) -> t = x*x; t*t).
>
> Since x*x*x*x is (((x*x)*x)*x) I don't think that transformation is
> actually within the C99 notion of contracting; it's reassociating the
> multiplications rather than evaluating some source expression atomically.

The standard says: "the intermediate operations in the contracted 
expression are evaluated as if to infinite precision and range, while 
the final operation is rounded to the format determined by the 
expression evaluation method" and this sounds full of interesting and 
perhaps unwanted cases.

So x*x*x*x -> (x**2)**2 is not a contraction.  But x*x*x*x -> 
__builtin_powi(x,4) may be a contraction depending on the implementation 
of __builtin_powi.

And contracting for example allows to evaluate (x + 1.0) - x as (x - x) 
+ 1.0, which is definitely outside.

> With my notion of contracting only within the front
> end when a conforming state of contracting is set (there would also be a
> "fast" state permitting the present contracting outside of source
> expressions, I suppose), this would actually be quite an easy pragma to
> implement (modulo the changes for supporting ternary GIMPLE statements
> everywhere) since only the front end would need to know about it; there
> would be no need to attach pragma states to individual operations through
> the optimizers as there would be for the other floating-point pragmas.

You don't need pragma states, you just need optimization barriers that 
the front-end can place easily, and a careful distinction throughout the 
folders between what is a contraction and what is not.  Of course you 
can start with the conservative definition that "nothing" is a 
contraction. :)

Paolo

Paolo