[llvm-dev] fenv.h vs the optimizer
Will via llvm-dev
llvm-dev at lists.llvm.org
Mon Aug 22 01:13:15 PDT 2016
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>
More information about the llvm-dev
mailing list