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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 8 19:49:47 PST 2018

On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote:
> On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>     Hi Kevin,
>     Thanks for reaching out about this, and thanks especially for
>     offering to help. I've had some other priorities that have
>     prevented me from making progress on this recently.
>     As far as I know, there is no support at all in clang for handling
>     the FENV_ACCESS pragma. I have a sample patch somewhere that I
>     created to demonstrate how the front end would create the
>     constrained intrinsics instead of normal FP operations, but
>     correctly implementing support for the pragma requires more front
>     end and language expertise than I possess. I believe Clark Nelson,
>     who does have such expertise, has this on his long term TODO list
>     but I don't know anything about the actual timeframe when the work
>     will begin.
> If you want to work on this side of things, the place to start would 
> be teaching the lexer to recognize the attribute and produce a 
> suitable annotation token, then teaching the parser to parse the token 
> in the places where the pragma can appear and to track the current 
> FENV_ACCESS state. Then you'll need to find a suitable AST 
> representation for the pragma (I have some ideas on this, feel free to 
> ask), both for the affected compound statements and for the affected 
> floating-point operations, build those representations when necessary, 
> and teach the various AST consumers (LLVM IR generation and constant 
> expression evaluation immediately spring to mind) how to handle them.

FWIW, I think it would be nice for the IRBuider to have a kind of 
"strict FP" state, kind of like how we have a "fast math" state for 
adding fast-math flags, that will cause CreateFAdd and friends to 
produce the associated intrinsics, instead of the IR instructions, when 
strictness is enabled.


>     On the LLVM side of things there are a few significant holes. As
>     you've noticed, the FP to integer conversions operations still
>     need intrinsics, as do fcmp, fptrunc, and fpext. There are
>     probably others that I'm overlooking. The FP to SI conversion has
>     an additional wrinkle that needs to be worked out in that the
>     default lowering of this conversion to machine instructions is not
>     exception safe.
>     In general, the current "strict FP" handling stops at instruction
>     selection. At the MachineIR level we don't currently have a
>     mechanism to prevent inappropriate optimizations based on floating
>     point constraints, or indeed to convey such constraints to the
>     backend. Implicit register use modeling may provide some
>     restriction on some architectures, but this is definitely lacking
>     for X86 targets. On the other hand, I'm not aware of any specific
>     current problems, so in many cases we may "get lucky" and have the
>     correct thing happen by chance. Obviously that's not a viable long
>     term solution. I have a rough plan for adding improved register
>     modeling to the X86 backend, which should take care of instruction
>     scheduling issues, but we'd still need a mechanism to prevent
>     constant folding optimizations and such.
>     As for what you could begin work on, it should be a fairly
>     straight-forward task to implement the intrinsics for fptosi,
>     fptoui, fcmp, fptrunc, and fpext. That would be a gentle
>     introduction. Beyond that, it would be very helpful to have some
>     pathfinding work done to solidify exactly what the remaining
>     shortcomings are. I have a patch somewhere (stale by now, but I
>     could refresh it pretty easily) that unconditionally converts all
>     FP operations to the equivalent constrained intrinsics. You could
>     use that to do testing and find out what's broken.
>     Thanks,
>     Andy
>     -----Original Message-----
>     From: Kevin P. Neal [mailto:kpn at neutralgood.org
>     <mailto:kpn at neutralgood.org>]
>     Sent: Monday, January 08, 2018 6:41 AM
>     To: Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org
>     <mailto:cfe-dev at lists.llvm.org>>
>     Cc: Richard Smith <richard at metafoo.co.uk
>     <mailto:richard at metafoo.co.uk>>; Kaylor, Andrew
>     <andrew.kaylor at intel.com <mailto:andrew.kaylor at intel.com>>; Marcus
>     Johnson <bumblebritches57 at gmail.com
>     <mailto:bumblebritches57 at gmail.com>>; wei.ding2 at amd.com
>     <mailto:wei.ding2 at amd.com>; Bob Huemmer <bob.huemmer at sas.com
>     <mailto:bob.huemmer at sas.com>>
>     Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
>     On Thu, Aug 31, 2017 at 05:03:17PM -0500, Hal Finkel via cfe-dev
>     wrote:
>     >    To be clear, we've had several extensive discussions about
>     this, on and
>     >    off list, and Andy has started adding the corresponding
>     intrinsics into
>     >    the IR. There was a presumption about a lack of mixing,
>     however, and we
>     >    do need to work out how to prevent mixing the native IR
>     operations with
>     >    the intrinsics (although, perhaps we just did that).
>     >     -Hal
>     What's the current status of this work? My employeer very much
>     needs this work done sooner rather than later, and I've been
>     tasked with helping make it happen.
>     What, exactly, still needs to be done to complete this work? I've
>     seen some of the discussions about it, and I've seen the
>     documentation on the new llvm constrained floating point
>     intrinsics. But clang I don't think supports them yet, fptosi is
>     not on the list anyway, and I'm not sure what else is needed. So
>     I'm asking, what all is needed and what can I work on to move this
>     forward?
>     Is there any work in progress code that anyone would be willing to
>     share?
>     For example, any code using the new intrinsics? Andy?
>     The specific case we're running into today is that we have code
>     being reordered in ways that trigger traps when handling a NaN.
>     This code:
>     #include <math.h>
>     int foo(double d) {
>        int x = (!isnan(d) ? (int)d : 45);
>        return x;
>     }
>     ... becomes this:
>     define signext i32 @foo(double) local_unnamed_addr #0 !dbg !10 {
>       tail call void @llvm.dbg.value(metadata double %0, i64 0,
>     metadata !15, metadata !17), !dbg !18
>       %2 = tail call signext i32 @__isnan(double %0) #3, !dbg !19
>       %3 = icmp eq i32 %2, 0, !dbg !19
>       %4 = fptosi double %0 to i32, !dbg !20
>       %5 = select i1 %3, i32 %4, i32 45, !dbg !19
>       tail call void @llvm.dbg.value(metadata i32 %5, i64 0, metadata
>     !16, metadata !17), !dbg !21
>       ret i32 %5, !dbg !22
>     }
>     So the fptosi gets moved _above_ the select and the trap happens.
>     This in code that was written to avoid a trap in exactly this case.
>     We're compiling with clang 5.0.0 "-g -O1" targeting SystemZ.
>     --
>     Kevin P. Neal http://www.pobox.com/~kpn/
>     <http://www.pobox.com/%7Ekpn/>
>           'Concerns about "rights" and "ownership" of domains are
>     inappropriate.
>      It is appropriate to be concerned about "responsibilities" and
>     "service"
>      to the community.' -- RFC 1591, page 4: March 1994
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-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/llvm-dev/attachments/20180108/b3263d2d/attachment.html>

More information about the llvm-dev mailing list