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

Hal Finkel via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 31 14:46:56 PDT 2017


On 08/31/2017 04:40 PM, Hal Finkel via cfe-dev 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.
>
>>
>> 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).
>
>  -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.

I agree with this: we can't mix them. If a function allows FP 
environment access anywhere, then we'll need to use the intrinsics 
everywhere. We'll also need to use noimplicitfloat. We'll need to 
disallow inlining as well where there's a mismatch (we could, for 
example, add an "fp_env_access" attribute, and disallow inlining when 
there's a caller/callee attribute mismatch).

  -Hal

>>
>> 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
>> 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
> 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/42d499cf/attachment.html>


More information about the cfe-dev mailing list