[cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
Hal Finkel via cfe-dev
cfe-dev at lists.llvm.org
Thu Aug 31 18:17:20 PDT 2017
On 08/31/2017 05:41 PM, Richard Smith wrote:
> If everyone's happy with that approach, I agree we're ready to start
> looking at the frontend side of things :-) I think there are a few
> open questions:
>
> * Is it ever worth outlining an FENV_ACCESS block from a function to
> minimize the scope in which optimizations are restricted? (Presumably
> in the long term, all the LLVM optimizations that can operate on FP
> operations will do the same thing to intrinsic calls that are in
> "never traps, rounds to nearest" mode, so it may well not be worthwhile.)
Outlining is probably a reasonable idea if there are floating-point
computations outside of the FENV_ACCESS blocks in the functions. The
tradeoffs here could be tricky, however, and I'd suggest waiting until
we find some motivating cases. Even long term, I don't expect parity
(just because if we're going to teach all of the transformations to
treat them identically, we might as well extend the semantics of the IR
operations themselves, and it's not clear to me that will even be
worthwhile).
> * What impact does FENV_ACCESS have on constant expression evaluation,
> particularly in C++11 onwards where some FP operations are required to
> be evaluated during compilation?
> * What happens if FENV_ACCESS is enabled at the end of a module?
Would you prefer that it stay within the module? I think I'd prefer that.
Thanks again,
Hal
> * How does FENV_ACCESS interact with namespaces? Does it only last
> until the `}` (like at block scope) or not?
>
> I've taken some of these to the C++ committee to see if they have
> opinions about how this feature should work in C++.
>
> On 31 August 2017 at 15:28, Kaylor, Andrew via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
> This sounds promising.
>
> I would not that when I added the strictfp attribute, I intended
> that the front end would attach this attribute to the callsite of
> all function calls within a scope that required strict floating
> point semantics. It was supposed to be a way of preventing calls
> to libm functions from being optimized as LibFunc calls without
> the front end needing to know which functions could be processed
> that way.
>
> I think it is a natural extension to use this attribute on
> functions that contain code requiring strict floating point
> handling, but the documentation will need to be updated.
>
> *From:*Hal Finkel [mailto:hfinkel at anl.gov <mailto:hfinkel at anl.gov>]
> *Sent:* Thursday, August 31, 2017 3:08 PM
> *To:* Richard Smith <richard at metafoo.co.uk
> <mailto:richard at metafoo.co.uk>>
> *Cc:* Kaylor, Andrew <andrew.kaylor at intel.com
> <mailto:andrew.kaylor at intel.com>>; 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 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
>
> _______________________________________________ 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/d6eb8160/attachment.html>
More information about the cfe-dev
mailing list