[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.
-Hal
>
> 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