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

Thu Aug 31 15:02:00 PDT 2017

On 31 August 2017 at 14:40, Hal Finkel via cfe-dev <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.)

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?

>  -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> 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]
>> *Sent:* Thursday, August 31, 2017 2:18 PM
>> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>
>> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>; Marcus Johnson <
>> bumblebritches57 at gmail.com>; 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> 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]
>> *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> 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]
>> *Sent:* Thursday, August 31, 2017 10:45 AM
>> *To:* Richard Smith <richard at metafoo.co.uk>; Marcus Johnson <
>> bumblebritches57 at gmail.com>
>> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>; Kaylor, Andrew <
>> 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> wrote:
>>
>> ^^^^^^
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> 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
>>
>> 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
>>
>>
>>
>> _______________________________________________ cfe-dev mailing list
>> 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 http://lists.llvm.org/cgi-bin/
>> mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing listcfe-dev at lists.llvm.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170831/8444b040/attachment.html>