[cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

[Kaylor, Andrew via cfe-dev]

I believe that we will rely on fedisableexcept() being marked as having unmodeled side-effects to prevent a hoist like that.

From: Richard Smith [mailto:richard at metafoo.co.uk]
Sent: Thursday, August 31, 2017 2:09 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: Marcus Johnson <bumblebritches57 at gmail.com>; Clang Dev <cfe-dev at lists.llvm.org>; wei.ding2 at amd.com
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

On 31 August 2017 at 11:09, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
There are still a few things missing from the optimizer to get it completely robust, but I think there is enough in place for front end work to begin.  As I think I’ve demonstrated in my recent attempt to contribute a clang patch I’m not skilled enough with the front end to be the person to pull this off without an excessive amount of oversight, but as Erich indicated we do have some good front end people here who have this on their TODO list.  It’s just not at the top of the TODO list yet.

If anyone is interested in the details of the LLVM side of things, there are constrained FP intrinisics (still marked as experimental at this point) documented in the language reference.  The initial patch can be seen here:

https://reviews.llvm.org/D27028

I’ve since added another group of intrinsics to handle the libm-equivalent intrinsics, and more recently Wei Ding contributed an fma intrinsic.

The idea is that the front end will emit the constrained intrinsics in place of equivalent general FP operations or intrinsics in scopes where FENV_ACCESS is enabled.  This will prevent the optimizer from making optimizations that assume default fenv settings (which is what we want the optimizer to do in all other cases).  Eventually, we’ll want to go back and teach specific optimizations to understand the intrinsics so that where possible optimizations can be performed in a manner consistent with dynamic rounding modes and strict exception handling.

How do you deal with the hoisting-into-fenv_access problem? Eg:

double f(double a, double b, double c) {
  {
#pragma STDC FENV_ACCESS ON
    feenableexcept(FE_OVERFLOW);
    double d = a * b;
    fedisableexcept(FE_OVERFLOW);
  }
  return c * d;
}

What stops llvm from hoisting the second fmul up to before the fedisableexcept?

-Andy

From: Hal Finkel [mailto:hfinkel at anl.gov<mailto:hfinkel at anl.gov>]
Sent: Thursday, August 31, 2017 10:45 AM
To: Richard Smith <richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>>; Marcus Johnson <bumblebritches57 at gmail.com<mailto:bumblebritches57 at gmail.com>>
Cc: Clang Dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>; Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?



On 08/31/2017 12:10 PM, Richard Smith via cfe-dev wrote:
Because no-one has implemented it. Patches would be welcome, but will need to start with a design and implementation of the requisite llvm extensions.

Yes. This is what Andrew Kaylor has been working on (cc'd).

 -Hal


On 31 Aug 2017 10:06, "Marcus Johnson via cfe-dev" <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
^^^^^^

_______________________________________________
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



_______________________________________________

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

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170831/1138bc9a/attachment.html>