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

Wed Mar 15 14:51:44 PDT 2017

> On Mar 15, 2017, at 2:30 PM, Hal Finkel <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.

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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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 <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

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