Re: PATCH - [tree-ssa] regrouping of expression tree for singlemultiply add.

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 26 Mar 2004, Fariborz Jahanian wrote:
> > Almost.  The patch looks much better, however, in the first "clause"
> > you need to check that *both* tree10 and tree11 are MULT_EXPR, and in
> > the second clause, you need to check both tree00 and tree01 are
> > MULT_EXPR.
>
> I left out tree10 and tree00 intentionally. In a more complicated case;
> such as:
> ( (a*b + c*d) + e*f) + r
> tree00 is (a*b+c*d) and checking for MULT_EXPR prevents re-association
> to take place (TREE_CODE(tree00) == PLUS_EXPR).

Indeed, but in this case you don't achieve any immediate improvement.

((a*b + c*d) + e*f) + r   will use 1 mult, 2 fmadds and an addition.
(a*b + c*d) + (e*f + r)   will use 1 mult, 2 fmadds and an addition.

Yes, in theory this expression could potentially be evaluated with
just 3 fmadds.  However that would require reordering operands and
transformations not in your current patch.  One step at a time, with
the current controversy with reassociation,  I think even with
-ffast-math we should only reassociate if we obtain some clear
performance benefit.

"(a + b*c) + d  -> a + (b*c + d)" simply replaces a perfectly good
"a + b*c" fmadd with the alternate "b*c + d".  However if we know
that a is a multiplication and that d isn't, we can guarantee a real
benefit.  If both a and d are VAR_DECLs, for example, we just upset
the number theorists for no good reason... :>

Roger
--