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

[Lang Hames]

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?

Cheers,
Lang.

On Sat, Jun 2, 2012 at 1:11 AM, Duncan Sands <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>> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120605/c458bf6a/attachment.html>