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

Thu Aug 31 14:55:03 PDT 2017

On 31 August 2017 at 14:48, Kaylor, Andrew via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I had considered the inlining issue, and updating the inliner to handle
> this was on my list of things yet to be done.  I’m not sure I understand
> what you’re saying about LTO.
>

The point about LTO was that you can't solve the inlining problem by using
intrinsics throughout an entire module if FENV_ACCESS is used anywhere,
because you might see code from outside the module.

There are some points about the standard specification that seem a bit
> unclear to me, specifically with regard to how things work if you call an
> FENV_ACCESS-off function from within an FENV_ACCESS-on scope.  I believe
> that when I talked with our front end guys here about that our conclusion
> was that doing that sort of thing is undefined behavior.  I’m not sure if
> this is related to your LTO concern or not.
>

I don't think that observation helps much, since you can call
FENV_ACCESS-on code from FENV_ACCESS-off code, which is equally
problematic. It's also not true that the above case results in UB: you only
get UB if you're in a non-default FP mode when you enter the
FENV_ACCESS-off code, or if that code attempts to inspect or alter the FP
environment -- so the hoisting problem still seems to exist.

In any event, you definitely raise some good questions that I don’t have
> answers for.  I’ll have to give this some more thought.
>
>
>
> I just want to add that one of the primary design goals in what I’ve done
> so far was to not doing anything that would inhibit optimizations or
> require extra work on the part of the optimization passes in the case where
> we don’t care about FENV_ACCESS.  That requirement makes attaching
> side-effects to the FP operations quite difficult.
>

Indeed; FWIW that approach seems like the right one to me. We need a very
strong barrier between anything that might use feenableexcept and anything
that might use LLVM's "pure" FP operations, and I don't believe we have
such a thing in LLVM IR yet. So I don't think we're ready for frontend work
on FENV_ACCESS, since we don't yet know how it will be represented in IR.

> -Andy
>
>
>
> *From:* Richard Smith [mailto:richard at metafoo.co.uk]
> *Sent:* Thursday, August 31, 2017 2:32 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?
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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 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/ac768bb3/attachment.html>