[PATCH] RFC for patch to add C99 fma/fmaf/fmal builtins

[Richard Guenther]

On Tue, Oct 5, 2010 at 1:32 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Mon, 4 Oct 2010, Michael Meissner wrote:
>
>> I happen to reread parts of the C99 standard recently, and noticed the FMA
>> builtins.  The current compiler defines fma{,f,l} builtins but does not provide
>> any code to expand the builtin.
>
> Indeed, such code would be useful.  Properly done - providing RTL (and
> ideally GENERIC/GIMPLE) operations for the fused operations - it would
> also pave the way for fixing the bug that operations of the form a*b+c get
> converted to fused operations on some targets regardless of whether they
> were written like that in a source language expression, by writing the RTL
> descriptions to describe the proper semantics of the affected instructions
> and not pretending that they are proper implementations of a*b+c - other
> parts of the compiler would then deal with converting a*b+c to a fused
> operation where appropriate rather than the back ends doing so.
>
> There have been various past discussions of this.  I'm afraid I didn't
> fully understand how the PAREN_EXPR approach some people mentioned in the
> thread <http://gcc.gnu.org/ml/gcc-patches/2010-06/subjects.html#02256> for
> representing what forms of contracting were permitted would work, but it
> was supposed to allow contracting (in this context, converting a*b+c to a
> fused operation if the target has one and the language permits) to be done
> on GIMPLE rather than needing to be done in the front end to have the
> required information about source language expressions.
>
> I would imagine a tristate option for contracting - options "off", "on"
> (conforming), "fast" (the present state, contracting even outside the
> bounds of source language expressions).
>
> As indicated in <http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01280.html>,
> I believe that once you've added the fma RTL operation it should be usable
> to describe all the versions with negated operands or results.  My only
> real comment about your present patch is that given the correct RTL it
> ought to be easy to extend it to cover the full range of related
> operations on Power Architecture processors (so that fma (a, b, -c) etc.
> get appropriately expanded), even without doing any of the other pieces.

It's on my TODO list for 4.6 to add the GENERIC/GIMPLE part of this,
so Mike, if you want to deal with the RTL pieces that would be nice.

As of the PAREN_EXPR reference, PAREN_EXPRs act as barriers
for association.  So to prevent contraction you'd write
PAREN_EXPR<a*b> + c which prevents re-associating (not sure
if that's the correct term) to PAREN_EXPR<a*b + c> and thus
contraction.  PAREN_EXPRs stay intact even with -ffast-math, so
you can do things like expanding round(x) to
PAREN_EXPR <PAREN_EXPR<x + 1e52> - 1e52> on the gimple
level.

I'm not sure PAREN_EXPR is useful for anything in the C frontend
though, it was introduced for Fortran frontend usage which allows
arbitrary association by default as long as one preserves paranteses.

Thanks,
Richard.