[cfe-dev] [llvm-dev] Why is #pragma STDC FENV_ACCESS not supported?
Hal Finkel via cfe-dev
cfe-dev at lists.llvm.org
Tue Jan 9 15:43:49 PST 2018
On 01/09/2018 04:30 PM, Richard Smith wrote:
> On 8 Jan 2018 19:50, "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org
> <mailto:cfe-dev at lists.llvm.org>> wrote:
>
> 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.
>
>
> I expect we'll need a "non-default FP environment" marker on each
> floating-point AST node (both on operations and on calls that could
> resolve to FP builtins) in order to properly handle constant
> expression evaluation for those things, so we will presumably have the
> relevant information to hand at the point of emitting an expression
> anyway. That said, this functionality may be useful if the IR
> representation needs to be different for FP operations appearing
> outside an FENV_ACCESS region but within a function that contains an
> FENV_ACCESS region (eg, using intrinsics rather than instructions).
I also think that an abstraction in the IRBuilder will make this easier
to use by other frontends (otherwise we'll have the (if (strict)
CreateIntrinsic else CreateFOp) logic repeated in multiple projects/places.
-Hal
>
> -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 <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>
>
> --
> 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/20180109/37265943/attachment.html>
More information about the cfe-dev
mailing list