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