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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 17:20:32 PDT 2017 

On 03/16/2017 06:23 PM, Adam Nemet wrote:
>
>> On Mar 16, 2017, at 4:04 PM, Adam Nemet via cfe-dev 
>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>>
>>> On Mar 16, 2017, at 3:25 PM, Hal Finkel <hfinkel at anl.gov 
>>> <mailto:hfinkel at anl.gov>> wrote:
>>>
>>>
>>> On 03/16/2017 04:13 PM, Adam Nemet 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 (-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.
>>>
>>> Are you saying this works because we don't block inlining when 
>>> functions attributes don't match or update the function attributes 
>>> to be more conservative when inlining? This is specifically one of 
>>> the issues we were avoiding by using FMFs. Frankly, the same issue 
>>> comes up with other fast-math properties, and I don't see why we 
>>> should handle this differently. I think that I'd prefer you stick 
>>> with the new flag.
>>
>> OK, so in the example:
>>
>> #pragma clang fast_math contract_fast(on)
>>  vect v1 = v2 * v3 + v4;
>> #pragma clang fast_math contract_fast(off)
>>
>> where all the operands are vectors with the typical implementation 
>> for the overload operators, we wouldn’t fp-contract unless the 
>> operator definitions use contract_fast too?
>
> I guess it’s the conservative thing to do since those functions may 
> have non-contractable operations.

Exactly; the problem is that this is the desirable behavior in some 
circumstances and undesirable in others, but I think that doing the 
conservative thing is the most self-consistent choice (and also allows 
users the most powerful fine-grained control).

Thanks again,
Hal

>
> Adam
>
>>
>> Adam
>>
>>>
>>>  -Hal
>>>
>>>>
>>>> Adam
>>>>
>>>>>
>>>>> Adam
>>>>>
>>>>>>
>>>>>>  -Hal
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Adam
>>>>>>>
>>>>>>>> I also think that having a "fast math" pragma is also a good 
>>>>>>>> idea (the fact that we can currently only specify fast-math 
>>>>>>>> settings on a translation-unit level is somewhat problematic).
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, IIUC, the function attribute as well as a FMF wouldn’t 
>>>>>>>>>> apply to the “ON” setting but only to the “FAST” mode (no way 
>>>>>>>>>> to distinguish source level statement in llvm IR).
>>>>>>>>
>>>>>>>> Right. We still have the existing fmuladd intrinsic method for 
>>>>>>>> dealing with the "ON" setting.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> Adam
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> —
>>>>>>>>>> Mehdi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also now that we have backend optimization remarks, I am 
>>>>>>>>>>>> planning to report missed optimization when we can’t fuse 
>>>>>>>>>>>> FMAs due “fast” not being on.  This will show up in the 
>>>>>>>>>>>> opt-viewer.  Then the user can opt in either with the 
>>>>>>>>>>>> command-line switch or the new function attribute.
>>>>>>>>>>>
>>>>>>>>>>> That seems useful.
>>>>>>>>>>>
>>>>>>>>>>> Thanks again,
>>>>>>>>>>> Hal
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Adam
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 15, 2017, at 6:27 AM, Renato Golin via cfe-dev 
>>>>>>>>>>>>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've been asking around people about the state of FP 
>>>>>>>>>>>>> contract, which
>>>>>>>>>>>>> seems to be "on" but it's not really behaving like it, at 
>>>>>>>>>>>>> least not as
>>>>>>>>>>>>> I would expect:
>>>>>>>>>>>>>
>>>>>>>>>>>>> int foo(float a, float b, float c) { return a*b+c; }
>>>>>>>>>>>>>
>>>>>>>>>>>>> $ clang -target aarch64-linux-gnu -O2 -S fma.c 
>>>>>>>>>>>>> -ffp-contract=on -o -
>>>>>>>>>>>>> (...)
>>>>>>>>>>>>> fmul s0, s0, s1
>>>>>>>>>>>>> fadd s0, s0, s2
>>>>>>>>>>>>> (...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> $ clang -target aarch64-linux-gnu -O2 -S fma.c 
>>>>>>>>>>>>> -ffp-contract=fast -o -
>>>>>>>>>>>>> (...)
>>>>>>>>>>>>> fmadd s0, s0, s1, s2
>>>>>>>>>>>>> (...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure this works in Fortran either, but defaulting 
>>>>>>>>>>>>> to "on" when
>>>>>>>>>>>>> (I believe) the language should allow contraction and not 
>>>>>>>>>>>>> doing it is
>>>>>>>>>>>>> not a good default.
>>>>>>>>>>>>>
>>>>>>>>>>>>> i haven't worked out what would be necessary to make it 
>>>>>>>>>>>>> work on a
>>>>>>>>>>>>> case-by-case basis (what kinds of fusions does C allow?) 
>>>>>>>>>>>>> to make sure
>>>>>>>>>>>>> we don't do all or nothing, but if we don't want to start that
>>>>>>>>>>>>> conversation now, then I'd recommend we just turn it all 
>>>>>>>>>>>>> the way to 11
>>>>>>>>>>>>> (like GCC) and let people turn it off if they really mean it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The rationale is that:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Contracted operations increase precision (less rounding 
>>>>>>>>>>>>> steps)
>>>>>>>>>>>>> * It performs equal or faster on all architectures I know 
>>>>>>>>>>>>> (true everywhere?)
>>>>>>>>>>>>> * Users already expect that (certainly, GCC users do)
>>>>>>>>>>>>> * Makes us look good on benchmarks :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> A recent SPEC2k6 comparison Linaro did for AArch64, enabling
>>>>>>>>>>>>> -ffp-contract=fast took the edge of GCC in a number of 
>>>>>>>>>>>>> cases and in
>>>>>>>>>>>>> some of them made them comparable in performance. So, any 
>>>>>>>>>>>>> reasons not
>>>>>>>>>>>>> to?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we go with it, we need to first finish the job that 
>>>>>>>>>>>>> Sebastian was
>>>>>>>>>>>>> dong on the test-suite, then just turn it on by default. A 
>>>>>>>>>>>>> second
>>>>>>>>>>>>> stage would be to add tests/benchmarks that explicitly test FP
>>>>>>>>>>>>> precision, so that we have some extra guarantee that we're 
>>>>>>>>>>>>> doing the
>>>>>>>>>>>>> right thing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Opinions?
>>>>>>>>>>>>>
>>>>>>>>>>>>> cheers,
>>>>>>>>>>>>> --renato
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cfe-dev mailing list
>>>>>>>>>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> LLVM Developers mailing list
>>>>>>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Hal Finkel
>>>>>>>>>>> Lead, Compiler Technology and Programming Languages
>>>>>>>>>>> Leadership Computing Facility
>>>>>>>>>>> Argonne National Laboratory
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cfe-dev mailing list
>>>>>>>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Hal Finkel
>>>>>>>> Lead, Compiler Technology and Programming Languages
>>>>>>>> Leadership Computing Facility
>>>>>>>> Argonne National Laboratory
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Hal Finkel
>>>>>> Lead, Compiler Technology and Programming Languages
>>>>>> Leadership Computing Facility
>>>>>> Argonne National Laboratory
>>>>
>>>
>>> -- 
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

More information about the llvm-dev mailing list