[llvm-commits] [cfe-commits] [PATCH] Add llvm.fmuladd intrinsic.

[Duncan Sands]

Hi Lang,

> I've committed the fmuladd intrinsic (since nobody seemed to have any objections
> to that) in r158014.
>
> Duncan - sorry, I only just saw your email. Using metadata for this seems like a
> reasonable solution too. Do you have an specific thoughts on the benefits of
> metadata vs an intrinsic here?

the benefit of metadata is that you can hopefully synthesize fmuladd from
fmul+fadd in the presence of the appropriate metadata on the fmul and the
fadd.  The disadvantage is that the whole fast-math metadata scheme doesn't
actually exist yet :)

Ciao, Duncan.

>
> Cheers,
> Lang.
>
> On Sat, Jun 2, 2012 at 1:11 AM, Duncan Sands <baldrick at free.fr
> <mailto:baldrick at free.fr>> wrote:
>
>     Hi John,
>
>     On 02/06/12 01:32, John McCall wrote:
>      > On Jun 1, 2012, at 11:28 AM, Douglas Gregor wrote:
>      >> On May 31, 2012, at 7:51 PM, Lang Hames <lhames at gmail.com
>     <mailto:lhames at gmail.com>
>      >> <mailto:lhames at gmail.com <mailto:lhames at gmail.com>>> wrote:
>      >>> Yep - I'm not sure what to do about that. At the moment all we have in the
>      >>> way of defaults is the language options DefaultFPContract value.
>     Perhaps it's
>      >>> reasonable to have a per-target DefaultFPContract value that can
>     override the
>      >>> language default. When it comes to explicitly referencing the pragma
>     I'm not
>      >>> sure what the best way to handle that is - As I understand it we won't know
>      >>> how many functions it applies to (and thus whether it's a good
>     candidate as a
>      >>> global default) until we've already parsed them.
>      >>
>      >> I think it's completely reasonable to have the target provide the
>     default, and
>      >> only add the FPContract attribute to the AST if it is either (a) specified
>      >> directly by the user, or (b) under control of a #pragma that provides a
>     value
>      >> that is not the default for that target. The accessor for "get the effective
>      >> FPContract value" will then check for the attribute and, if not present,
>      >> return the target's default.
>      >>
>      >> I think this gives us what we want---per-target control, low memory usage in
>      >> the common case, and a clean way to fit it into the AST.
>      >
>      > To keep the list informed: I'd missed that this pragma was a C feature
>     that we
>      > hadn't been supporting. Given that, we really should design our AST to
>     support
>      > the actual language feature, which includes lexically scoping the pragma. We
>      > should also support applying these semantics to expressions at global scope;
>      > that's not possible in C (because floating-point expressions can't be
>     constant
>      > expressions), but it is in C++ (because C++11 constant expressions are much
>      > broader than C's and, more importantly, because C++ permits non-constant
>      > initializers). Both of these strongly suggest remembering this as a bit on
>      > UnaryOperator and BinaryOperator, to be set at parse-time and preserved
>     through
>      > all transformations.
>
>     I have a plan to attach various fast-math permissions to floating point
>     operations by enhancing fpmath metadata.  Maybe this info (whatever it is [*])
>     should go there too?
>
>     Ciao, Duncan.
>
>     [*] I haven't been following the thread.
>     _______________________________________________
>     llvm-commits mailing list
>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>