Hal Finkel via llvm-dev
2017-Mar-16 22:25 UTC
[llvm-dev] [cfe-dev] [RFC] FP Contract = fast?
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. -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/cd62be00/attachment-0001.html>
Adam Nemet via llvm-dev
2017-Mar-16 23:04 UTC
[llvm-dev] [cfe-dev] [RFC] FP Contract = fast?
> On Mar 16, 2017, at 3:25 PM, Hal Finkel <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 <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? 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 <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 >> > > -- > 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/deee58e5/attachment-0001.html>
Adam Nemet via llvm-dev
2017-Mar-16 23:23 UTC
[llvm-dev] [cfe-dev] [RFC] FP Contract = fast?
> On Mar 16, 2017, at 4:04 PM, Adam Nemet via cfe-dev <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 <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. 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 <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 >>> >> >> -- >> 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>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/1f2b0d8f/attachment.html>