[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