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

Hal Finkel via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 31 15:07:53 PDT 2017


On 08/31/2017 05:02 PM, Richard Smith wrote:
> On 31 August 2017 at 14:40, Hal Finkel via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     On 08/31/2017 04:31 PM, Richard Smith via cfe-dev wrote:
>
>>     I think that's also not enough; you'd get the same problem after
>>     inlining, and across modules with LTO. You would need to also
>>     prevent any interprocedural code motion across a FENV_ACCESS /
>>     non-FENV_ACCESS boundary.
>
>     Or we prevent inlining.
>
>
> Sure, I was considering that to be a form of interprocedural code 
> motion :)
>
>>     And even that doesn't seem to be enough. Suppose that some scalar
>>     optimization pass finds a clever way to converts some integer
>>     operation into a floating-point operation, such that it can prove
>>     that the FP values never overflow (I believe Chandler has an
>>     example of this that comes up in some real crypto code). Now
>>     suppose there's a case where the integer operands are undef, but
>>     that the code in question is bypassed in that case. If the FP
>>     operations get hoisted, and you happen to have FP exceptions
>>     enabled, you have a potential miscompile.
>
>     Good point. However, that's not a new problem, and we currently
>     deal with this by respecting the noimplicitfloat attribute (and I
>     think we'd definitely need to use that attribute if we allow
>     fooling with the FP environment).
>
>
> OK, so the idea would be that we'd lower a function containing 
> FENV_ACCESS (or possibly an outlined block of such a function) with 
> intrinsics for all FP operations, specially-annotated libm function 
> calls, and noimplicitfloat and strictfp attributes to prevent 
> generation of new FP operations and inlining into non-strictfp 
> functions. Right? (And we could imagine a verifier check that ensures 
> that you don't have pure FP operations inside a strictfp function.)

Yes, exactly.

>
> Given the function annotations, do we need special intrinsics at all, 
> or could we instead require that passes check whether the enclosing 
> function is marked strictfp before optimizing, in the same way that 
> some optimizations must be gated by a check for noimplicitfloat?

That's another possible design. We decided that the intrinsics were less 
intrusive. The problems is that it's not just FP-specific optimizations 
that would need to check the attribute, it is also other optimizations 
doing other kinds of code motion and value propagation. Having IR-level 
operations that are side-effect-free, except when some special function 
attribute is present, seems undesirable.

  -Hal

>      -Hal
>
>
>>
>>     Fundamentally, it seems to me that feenableexcept is unsound in
>>     the current LLVM IR model of floating point, if we assume that
>>     fadd, fmul, fsub etc do not have side-effects.
>>
>>     On 31 August 2017 at 14:20, Kaylor, Andrew via cfe-dev
>>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>         If that’s the case, we may need to use the constrained
>>         intrinsics for all FP operations when FENV_ACCESS is enabled
>>         anywhere in a function.
>>
>>         *From:*Richard Smith [mailto:richard at metafoo.co.uk
>>         <mailto:richard at metafoo.co.uk>]
>>         *Sent:* Thursday, August 31, 2017 2:18 PM
>>         *To:* Kaylor, Andrew <andrew.kaylor at intel.com
>>         <mailto:andrew.kaylor at intel.com>>
>>         *Cc:* Clang Dev <cfe-dev at lists.llvm.org
>>         <mailto:cfe-dev at lists.llvm.org>>; Marcus Johnson
>>         <bumblebritches57 at gmail.com
>>         <mailto:bumblebritches57 at gmail.com>>; wei.ding2 at amd.com
>>         <mailto:wei.ding2 at amd.com>
>>
>>
>>         *Subject:* Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not
>>         supported?
>>
>>         On 31 August 2017 at 14:14, Kaylor, Andrew via cfe-dev
>>         <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>             I believe that we will rely on fedisableexcept() being
>>             marked as having unmodeled side-effects to prevent a
>>             hoist like that.
>>
>>         fadd can be hoisted past *anything*, can't it?
>>
>>             *From:*Richard Smith [mailto:richard at metafoo.co.uk
>>             <mailto:richard at metafoo.co.uk>]
>>             *Sent:* Thursday, August 31, 2017 2:09 PM
>>             *To:* Kaylor, Andrew <andrew.kaylor at intel.com
>>             <mailto:andrew.kaylor at intel.com>>
>>             *Cc:* Marcus Johnson <bumblebritches57 at gmail.com
>>             <mailto:bumblebritches57 at gmail.com>>; Clang Dev
>>             <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>;
>>             wei.ding2 at amd.com <mailto: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
>>                 <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
>>                         <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
>>                     <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
>>                 <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
>>             <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
>>         <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
>>     <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
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev> 
>
-- 
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/cfe-dev/attachments/20170831/570f9bd1/attachment.html>


More information about the cfe-dev mailing list