[llvm-dev] [cfe-dev] [RFC] FP Contract = fast?

[Mehdi Amini via llvm-dev]

> On Mar 16, 2017, at 2:13 PM, Adam Nemet <anemet at apple.com> wrote:
> 
>> 
>> On Mar 15, 2017, at 2:51 PM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote:
>> 
>>> 
>>> On Mar 15, 2017, at 2:30 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
>>> 
>>> 
>>> 
>>> On 03/15/2017 04:05 PM, Adam Nemet wrote:
>>>> 
>>>>> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 03/15/2017 01:47 PM, Adam Nemet wrote:
>>>>>> 
>>>>>>> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 03/15/2017 12:10 PM, Adam Nemet via llvm-dev wrote:
>>>>>>>>> Relevant to this discussion is http://bugs.llvm.org/show_bug.cgi?id=25721 <http://bugs.llvm.org/show_bug.cgi?id=25721> (-ffp-contract=fast does not work with LTO).  I am working on adding function attributes for fp-contract=fast which should fix this.
>>>>>>>> 
>>>>>>>> Great!
>>>>>>>> 
>>>>>>> 
>>>>>>> A function attribute would be a strict improvement over today: LLVM can’t do contraction today. But actually I’m not sure if it is the long term right choice: attributes don’t combine well with inlining for instance. You mentioned FMF earlier, why don’t we have a FMF to allow contraction?
>>>>>> 
>>>>>> OK, I thought that the prerequisite for that was a fast-math pragma which I don’t think is something we have (I want to be able to specify contract=fast on smaller granularity than module).  But now that I think more about, we should be able to turn a user function attribute into FMF in the front-end which is the most flexible. 
>>>>> 
>>>>> I agree, a FMF is the way to go and we can then control it with the pragma. We can use the STDC FP_CONTRACT pragma for contraction;
>>>> 
>>>> Just to confirm, do you mean to introduce a “fast” option to the pragma, e.g.:
>>>> 
>>>> #pragma STDC FP_CONTRACT FAST
>>> 
>>> That's a good point. If we don't add something like this, then we'd be able to turn the fast mode off with the pragma, but then not be able to turn it back on ;)
>>> 
>>> So, yes, except that I'm somewhat hesitant to invade the 'STDC' space with vendor extensions. If we generally introduce a pragma to control FMFs, maybe we should just use that instead? I don't have a clear idea on the syntax, but for example, if we had some pragma that let us do
>>> 
>>> #pragma clang fast_math or #pragma clang fast_math nnan(off) contract(on) or whatever then we could use that. What do you think?
>> 
>> That looks great; it nicely matches the internal representation.  Let me take a stab at this.
> 
> Thinking more about this, I am back to thinking that a function attribute is the better solution for this than FMF, at least before inlining.
> 
> Consider the standard example where we want this to trigger: an overloaded addition and multiplier operator for a vector class.
> 
> In this case, we want the fadd and the fmul in the inlined functions to have the FMF as well but we don’t necessarily want to mark the overloaded operators with the pragma; we may be only comfortable contracting at this call site.
> 
> You don’t have this problem if you mark the containing function FP-contractable.  Effectively what we want is to outline the block within the pragma into a function and tag it with the attribute.
> 
> During inlining we can still transform the function attribute into FMF.
> 
> So I think I am going back to implementing fp-contract=fast as a function attribute as the first step unless there are any objections.

I’m objecting to “as the first step” part only :) 
Either it is the right thing to do, or it is not! (You seem to advocate above that we should do it this way, in the absolute, not as a first step)

On the general direction, I feel that what you’re describing applies equally to any FMF, so it is not clear to me right now why fp-contract is fundamentally different from other FMF, can you clarify that? 

— 
Mehdi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/d93bc770/attachment.html>