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

Duncan Sands baldrick at free.fr
Sat Jun 2 01:11:15 PDT 2012


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.



More information about the llvm-commits mailing list