[cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
Kevin P. Neal via cfe-dev
cfe-dev at lists.llvm.org
Mon Jan 8 06:41:16 PST 2018
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/
'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
More information about the cfe-dev
mailing list