Howdy all,
I've been playing around with programs that use the C11 fenv.h.
It seems that, currently, the LLVM compiler does not regard to the
exception-flag side-effects of floating point operations?
When run on my macbook, the example code on
http://en.cppreference.com/w/c/numeric/fenv/FE_exceptions does not print
all the expected exceptions.
Other examples:
void foo() {
fesetround(FE_DOWNWARD);
printf("foo downward: %f\n", rint(0.5));
fesetround(FE_UPWARD);
printf("foo upward: %f\n", rint(0.5));
}
If compiled with optimization, only one call to rint() is made and the
result is reused.
void bar(double a, double b) {
feclearexcept(FE_INEXACT);
a / b;
printf("bar %f / %f is %sexact\n", a, b,
fetestexcept(FE_INEXACT)?
"in": "");
}
The compiler omits the divide as the result is unused. And so on.
Presumably this has never worked? And perhaps LLVM is no worse than
other compilers in this regard?
Is there any appetite to fix it? What kind of changes would need to be
made?
Thx,
Will
On 18 Aug 2016, at 09:12, Will via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Presumably this has never worked? And perhaps LLVM is no worse than other compilers in this regard?Correct, LLVM does not yet respect any of the floating point env stuff and clang does not support the related pragmas.> Is there any appetite to fix it? What kind of changes would need to be made?It is likely to require new floating point operations and some auditing of the instructions. I think various people who were interested in Fortran support will need something similar, as the C99 floating point environment stuff was intended to make porting Fortran code easier. David
LLVM has never really supported fenv.h: https://llvm.org/bugs/show_bug.cgi?id=8100 Even if we added support for the rounding modes, we don't support non-call exceptions either: https://llvm.org/bugs/show_bug.cgi?id=1269 I think there is interest in addressing the rounding mode stuff, but less interest in modelling FP side effects. Medhi had some ideas around this. On Thu, Aug 18, 2016 at 1:12 AM, Will via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Howdy all, > > I've been playing around with programs that use the C11 fenv.h. > > It seems that, currently, the LLVM compiler does not regard to the > exception-flag side-effects of floating point operations? > > When run on my macbook, the example code on http://en.cppreference.com/w/c > /numeric/fenv/FE_exceptions does not print all the expected exceptions. > > Other examples: > > void foo() { > fesetround(FE_DOWNWARD); > printf("foo downward: %f\n", rint(0.5)); > fesetround(FE_UPWARD); > printf("foo upward: %f\n", rint(0.5)); > } > > If compiled with optimization, only one call to rint() is made and the > result is reused. > > void bar(double a, double b) { > feclearexcept(FE_INEXACT); > a / b; > printf("bar %f / %f is %sexact\n", a, b, fetestexcept(FE_INEXACT)? > "in": ""); > } > > The compiler omits the divide as the result is unused. And so on. > > Presumably this has never worked? And perhaps LLVM is no worse than other > compilers in this regard? > > Is there any appetite to fix it? What kind of changes would need to be > made? > > Thx, > > Will > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160818/8236db5a/attachment.html>
Oops. Looks like I accidently dropped the mailing list when replying to this.
From: Kaylor, Andrew
Sent: Thursday, August 18, 2016 10:02 AM
To: 'Reid Kleckner' <rnk at google.com>; Will <will at
millcomputing.com>; Tim Amini Golling <mehdi.amini at apple.com>;
Chandler Carruth (chandlerc at gmail.com) <chandlerc at gmail.com>
Subject: RE: [llvm-dev] fenv.h vs the optimizer
We are definitely interested in correctly handling the FP side effects.
I’ve been reading up on the past community discussions of this in hopes of
bringing this back into focus. The last discussion I found on the topic was
this thread started by Medhi in February:
http://lists.llvm.org/pipermail/llvm-dev/2016-February/094869.html
Chandler made a proposal in that thread that seemed to be widely agreed upon,
but then as far as I can tell nothing was done to implement it.
-Andy
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid
Kleckner via llvm-dev
Sent: Thursday, August 18, 2016 8:42 AM
To: Will <will at millcomputing.com<mailto:will at
millcomputing.com>>; Tim Amini Golling <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>>
Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>
Subject: Re: [llvm-dev] fenv.h vs the optimizer
LLVM has never really supported fenv.h:
https://llvm.org/bugs/show_bug.cgi?id=8100
Even if we added support for the rounding modes, we don't support non-call
exceptions either:
https://llvm.org/bugs/show_bug.cgi?id=1269
I think there is interest in addressing the rounding mode stuff, but less
interest in modelling FP side effects. Medhi had some ideas around this.
On Thu, Aug 18, 2016 at 1:12 AM, Will via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Howdy all,
I've been playing around with programs that use the C11 fenv.h.
It seems that, currently, the LLVM compiler does not regard to the
exception-flag side-effects of floating point operations?
When run on my macbook, the example code on
http://en.cppreference.com/w/c/numeric/fenv/FE_exceptions does not print all the
expected exceptions.
Other examples:
void foo() {
fesetround(FE_DOWNWARD);
printf("foo downward: %f\n", rint(0.5));
fesetround(FE_UPWARD);
printf("foo upward: %f\n", rint(0.5));
}
If compiled with optimization, only one call to rint() is made and the result is
reused.
void bar(double a, double b) {
feclearexcept(FE_INEXACT);
a / b;
printf("bar %f / %f is %sexact\n", a, b, fetestexcept(FE_INEXACT)?
"in": "");
}
The compiler omits the divide as the result is unused. And so on.
Presumably this has never worked? And perhaps LLVM is no worse than other
compilers in this regard?
Is there any appetite to fix it? What kind of changes would need to be made?
Thx,
Will
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160818/a4c12a3a/attachment.html>
We’re in the process of trying to figure out a good way to harmonize FP exception handling and rounding with the related issues in vector masking. Obviously we don’t want to have completely different solutions for these closely related problems. We’re looking at ways to do something along the lines of Chandler’s proposal that will also handle the problem of false exceptions in masked vector lanes, but we want to make sure that whatever we do won’t limit the possibilities of optimizing FP code while correctly handling fenv access because we also care a lot about that. BTW, I’m not using the royal we here. I mean to indicate that I’m working with other people here at Intel to put together something that isn’t half baked when we propose it. We were hoping to have a BOF session at the upcoming LLVM Dev Meeting to talk about this, but of course I’m happy to discuss it before then too. -Andy From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Thursday, August 18, 2016 10:31 AM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: Reid Kleckner <rnk at google.com>; Will <will at millcomputing.com>; Chandler Carruth (chandlerc at gmail.com) <chandlerc at gmail.com> Subject: Re: [llvm-dev] fenv.h vs the optimizer Great, feel free to CC me and Steve Canon on the patches! — Mehdi On Aug 18, 2016, at 10:22 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:> That’s where we are right now, “someone” needs to step up and drives this, interested? :)Yes! From: mehdi.amini at apple.com<mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com] Sent: Thursday, August 18, 2016 10:17 AM To: Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> Cc: Reid Kleckner <rnk at google.com<mailto:rnk at google.com>>; Will <will at millcomputing.com<mailto:will at millcomputing.com>>; Chandler Carruth (chandlerc at gmail.com<mailto:chandlerc at gmail.com>) <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> Subject: Re: [llvm-dev] fenv.h vs the optimizer On Aug 18, 2016, at 10:01 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: We are definitely interested in correctly handling the FP side effects. I’ve been reading up on the past community discussions of this in hopes of bringing this back into focus. The last discussion I found on the topic was this thread started by Medhi in February: http://lists.llvm.org/pipermail/llvm-dev/2016-February/094869.html Chandler made a proposal in that thread that seemed to be widely agreed upon, but then as far as I can tell nothing was done to implement it. That’s where we are right now, “someone” needs to step up and drives this, interested? :) — Mehdi -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Thursday, August 18, 2016 8:42 AM To: Will <will at millcomputing.com<mailto:will at millcomputing.com>>; Tim Amini Golling <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: Re: [llvm-dev] fenv.h vs the optimizer LLVM has never really supported fenv.h: https://llvm.org/bugs/show_bug.cgi?id=8100 Even if we added support for the rounding modes, we don't support non-call exceptions either: https://llvm.org/bugs/show_bug.cgi?id=1269 I think there is interest in addressing the rounding mode stuff, but less interest in modelling FP side effects. Medhi had some ideas around this. On Thu, Aug 18, 2016 at 1:12 AM, Will via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Howdy all, I've been playing around with programs that use the C11 fenv.h. It seems that, currently, the LLVM compiler does not regard to the exception-flag side-effects of floating point operations? When run on my macbook, the example code on http://en.cppreference.com/w/c/numeric/fenv/FE_exceptions does not print all the expected exceptions. Other examples: void foo() { fesetround(FE_DOWNWARD); printf("foo downward: %f\n", rint(0.5)); fesetround(FE_UPWARD); printf("foo upward: %f\n", rint(0.5)); } If compiled with optimization, only one call to rint() is made and the result is reused. void bar(double a, double b) { feclearexcept(FE_INEXACT); a / b; printf("bar %f / %f is %sexact\n", a, b, fetestexcept(FE_INEXACT)? "in": ""); } The compiler omits the divide as the result is unused. And so on. Presumably this has never worked? And perhaps LLVM is no worse than other compilers in this regard? Is there any appetite to fix it? What kind of changes would need to be made? Thx, Will _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160818/6c4680b1/attachment.html>
I really like Chandler's approach! By passing the state and status in and out as arguments and returns, rather than as side channels and side effects, the compiler will be able to do its normal goodness without breaking correctness :D I am a bit cautious when Chandler says that InstCombine should lower the intrinsics if it is default (i.e. round-nearest) and the flags are not used. It seems legitimate for that exact intrinsic to be used by developers who especially want round-nearest in code where they know the dynamic rounding mode may not be default..? Here's something to ponder: does exception trapping mean that the new intrinsic functions have side-effects? Not all targets support exception trapping. I believe ARM64 is an example mainstream target that doesn't support exception traps. If a target doesn't support trapping, or if the intrinsic doesn't ask for it, then perhaps this allows the intrinsics to be const? The standard C math functions (pow, rint, sqrt etc) are already intrinsics. Will these also be parameterised? (I have been using Debian code search https://github.com/williame/debian-code-search-cli to find examples of fenv usage 'in the wild', and its very very sparse. However, there are a handful of examples where someone doing interval arithmetic or something, and in the cases hopefully we can parameterise the C math function intrinsics so backends can use explicit rounding ops if they have them.) /Will On 18/08/16 20:14, Kaylor, Andrew wrote:> > We’re in the process of trying to figure out a good way to harmonize > FP exception handling and rounding with the related issues in vector > masking. Obviously we don’t want to have completely different > solutions for these closely related problems. We’re looking at ways > to do something along the lines of Chandler’s proposal that will also > handle the problem of false exceptions in masked vector lanes, but we > want to make sure that whatever we do won’t limit the possibilities of > optimizing FP code while correctly handling fenv access because we > also care a lot about that. > > BTW, I’m not using the royal we here. I mean to indicate that I’m > working with other people here at Intel to put together something that > isn’t half baked when we propose it. We were hoping to have a BOF > session at the upcoming LLVM Dev Meeting to talk about this, but of > course I’m happy to discuss it before then too. > > -Andy > > *From:*mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > *Sent:* Thursday, August 18, 2016 10:31 AM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* Reid Kleckner <rnk at google.com>; Will <will at millcomputing.com>; > Chandler Carruth (chandlerc at gmail.com) <chandlerc at gmail.com> > *Subject:* Re: [llvm-dev] fenv.h vs the optimizer > > Great, feel free to CC me and Steve Canon on the patches! > > — > > Mehdi > > On Aug 18, 2016, at 10:22 AM, Kaylor, Andrew > <andrew.kaylor at intel.com <mailto:andrew.kaylor at intel.com>> wrote: > > > That’s where we are right now, “someone” needs to step up and > drives this, interested? :) > > Yes! > > *From:*mehdi.amini at apple.com <mailto:mehdi.amini at apple.com> > [mailto:mehdi.amini at apple.com] > *Sent:*Thursday, August 18, 2016 10:17 AM > *To:*Kaylor, Andrew <andrew.kaylor at intel.com > <mailto:andrew.kaylor at intel.com>> > *Cc:*Reid Kleckner <rnk at google.com <mailto:rnk at google.com>>; Will > <will at millcomputing.com <mailto:will at millcomputing.com>>; Chandler > Carruth (chandlerc at gmail.com <mailto:chandlerc at gmail.com>) > <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> > *Subject:*Re: [llvm-dev] fenv.h vs the optimizer > > On Aug 18, 2016, at 10:01 AM, Kaylor, Andrew > <andrew.kaylor at intel.com <mailto:andrew.kaylor at intel.com>> wrote: > > We are definitely interested in correctly handling the FP side > effects. > > I’ve been reading up on the past community discussions of this > in hopes of bringing this back into focus. The last > discussion I found on the topic was this thread started by > Medhi in February: > > http://lists.llvm.org/pipermail/llvm-dev/2016-February/094869.html > > Chandler made a proposal in that thread that seemed to be > widely agreed upon, but then as far as I can tell nothing was > done to implement it. > > That’s where we are right now, “someone” needs to step up and > drives this, interested? :) > > — > > Mehdi > > > > > -Andy > > *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org]*On > Behalf Of*Reid Kleckner via llvm-dev > *Sent:*Thursday, August 18, 2016 8:42 AM > *To:*Will <will at millcomputing.com > <mailto:will at millcomputing.com>>; Tim Amini Golling > <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> > *Cc:*llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> > *Subject:*Re: [llvm-dev] fenv.h vs the optimizer > > LLVM has never really supported fenv.h: > > https://llvm.org/bugs/show_bug.cgi?id=8100 > > Even if we added support for the rounding modes, we don't > support non-call exceptions either: > > https://llvm.org/bugs/show_bug.cgi?id=1269 > > I think there is interest in addressing the rounding mode > stuff, but less interest in modelling FP side effects. Medhi > had some ideas around this. > > On Thu, Aug 18, 2016 at 1:12 AM, Will via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Howdy all, > > I've been playing around with programs that use the C11 > fenv.h. > > It seems that, currently, the LLVM compiler does not > regard to the exception-flag side-effects of floating > point operations? > > When run on my macbook, the example code > onhttp://en.cppreference.com/w/c/numeric/fenv/FE_exceptionsdoes > not print all the expected exceptions. > > Other examples: > > void foo() { > fesetround(FE_DOWNWARD); > printf("foo downward: %f\n", rint(0.5)); > fesetround(FE_UPWARD); > printf("foo upward: %f\n", rint(0.5)); > } > > If compiled with optimization, only one call to rint() is > made and the result is reused. > > void bar(double a, double b) { > feclearexcept(FE_INEXACT); > a / b; > printf("bar %f / %f is %sexact\n", a, b, > fetestexcept(FE_INEXACT)? "in": ""); > } > > The compiler omits the divide as the result is unused. > And so on. > > Presumably this has never worked? And perhaps LLVM is no > worse than other compilers in this regard? > > Is there any appetite to fix it? What kind of changes > would need to be made? > > Thx, > > Will > > _______________________________________________ > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160822/cc2a6c64/attachment.html>