<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 01/09/2018 04:30 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQqmBUTOsSXytrhjc2wQh93Fm-Kfwn7F58-7NNdB6Lm_KuQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div dir="auto">
<div>
<div class="gmail_extra">
<div class="gmail_quote">On 8 Jan 2018 19:50, "Hal Finkel
via cfe-dev" <<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:
<blockquote class="m_5096431365501841374quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_5096431365501841374quoted-text">
<div
class="m_5096431365501841374m_-6809584157971477114moz-cite-prefix">On
01/08/2018 07:06 PM, Richard Smith via llvm-dev
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 8 January 2018
at 11:15, Kaylor, Andrew via llvm-dev <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Hi Kevin,<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
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.<br>
</div>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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).</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAOfiQqmBUTOsSXytrhjc2wQh93Fm-Kfwn7F58-7NNdB6Lm_KuQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="m_5096431365501841374quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> -Hal
<div class="m_5096431365501841374elided-text"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Andy<br>
<span><br>
<br>
-----Original Message-----<br>
From: Kevin P. Neal [mailto:<a
moz-do-not-send="true"
href="mailto:kpn@neutralgood.org"
target="_blank">kpn@neutralgood.org</a>]<br>
Sent: Monday, January 08, 2018 6:41 AM<br>
To: Hal Finkel via cfe-dev <<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>><br>
Cc: Richard Smith <<a
moz-do-not-send="true"
href="mailto:richard@metafoo.co.uk"
target="_blank">richard@metafoo.co.uk</a>>;
Kaylor, Andrew <<a
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"
target="_blank">andrew.kaylor@intel.com</a>>;
Marcus Johnson <<a
moz-do-not-send="true"
href="mailto:bumblebritches57@gmail.com"
target="_blank">bumblebritches57@gmail.com</a>>;
<a moz-do-not-send="true"
href="mailto:wei.ding2@amd.com"
target="_blank">wei.ding2@amd.com</a>;
Bob Huemmer <<a
moz-do-not-send="true"
href="mailto:bob.huemmer@sas.com"
target="_blank">bob.huemmer@sas.com</a>><br>
Subject: Re: [cfe-dev] Why is #pragma
STDC FENV_ACCESS not supported?<br>
<br>
</span>
<div>
<div
class="m_5096431365501841374m_-6809584157971477114h5">On
Thu, Aug 31, 2017 at 05:03:17PM
-0500, Hal Finkel via cfe-dev wrote:<br>
> To be clear, we've had
several extensive discussions about
this, on and<br>
> off list, and Andy has
started adding the corresponding
intrinsics into<br>
> the IR. There was a
presumption about a lack of mixing,
however, and we<br>
> do need to work out how to
prevent mixing the native IR
operations with<br>
> the intrinsics (although,
perhaps we just did that).<br>
> -Hal<br>
<br>
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.<br>
<br>
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?<br>
<br>
Is there any work in progress code
that anyone would be willing to
share?<br>
For example, any code using the new
intrinsics? Andy?<br>
<br>
<br>
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:<br>
<br>
#include <math.h><br>
<br>
int foo(double d) {<br>
int x = (!isnan(d) ? (int)d :
45);<br>
return x;<br>
}<br>
<br>
... becomes this:<br>
<br>
define signext i32 @foo(double)
local_unnamed_addr #0 !dbg !10 {<br>
tail call void
@llvm.dbg.value(metadata double %0,
i64 0, metadata !15, metadata !17),
!dbg !18<br>
%2 = tail call signext i32
@__isnan(double %0) #3, !dbg !19<br>
%3 = icmp eq i32 %2, 0, !dbg !19<br>
%4 = fptosi double %0 to i32, !dbg
!20<br>
%5 = select i1 %3, i32 %4, i32 45,
!dbg !19<br>
tail call void
@llvm.dbg.value(metadata i32 %5, i64
0, metadata !16, metadata !17), !dbg
!21<br>
ret i32 %5, !dbg !22<br>
}<br>
<br>
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.<br>
<br>
We're compiling with clang 5.0.0 "-g
-O1" targeting SystemZ.<br>
--<br>
Kevin P. Neal
<a moz-do-not-send="true"
href="http://www.pobox.com/%7Ekpn/"
rel="noreferrer" target="_blank">http://www.pobox.com/~kpn/</a><br>
'Concerns about "rights" and
"ownership" of domains are
inappropriate.<br>
It is appropriate to be concerned
about "responsibilities" and
"service"<br>
to the community.' -- RFC 1591,
page 4: March 1994<br>
______________________________<wbr>_________________<br>
</div>
</div>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset
class="m_5096431365501841374m_-6809584157971477114mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="m_5096431365501841374m_-6809584157971477114moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" class="m_5096431365501841374m_-6809584157971477114moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div><div class="m_5096431365501841374quoted-text"><pre class="m_5096431365501841374m_-6809584157971477114moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></div>
______________________________<wbr>_________________
cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a>
</blockquote></div>
</div></div></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre></body></html>