<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/10/2017 06:17 PM, Kaylor, Andrew via llvm-dev wrote:<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765C71@ORSMSX115.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Background<o:p></o:p></p>
<p class="MsoNormal">I’ve been working on adding the necessary
support to LLVM for clang to be able to support the STDC
FENV_ACCESS pragma, which basically allows users to modify
rounding mode at runtime and depend on the value of
floating-point status flags or to unmask floating point
exceptions without unexpected side effects. I’ve committed an
initial patch (r293226) that adds constrained intrinsics for
the basic FP operations, and I have a patch up for review now
(<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D32319">https://reviews.llvm.org/D32319</a>) that adds constrained
versions of a number of libm-like FP intrinsics.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Current problem<o:p></o:p></p>
<p class="MsoNormal">Now I’m trying to make sure I have a good
solution for the way in which the optimizer handles recognized
calls to libm functions (sqrt, pow, cos, sin, etc.).
Basically, I need to prevent all passes from making any
modifications to these calls that would make assumptions about
rounding mode or improperly affect the FP status flags (either
suppressing flags that should be present or setting flags that
should not be set). For instance, there are circumstances in
which the optimizer will constant fold a call to one of these
functions if the value of the arguments are known at compile
time, but this constant folding generally assumes the default
rounding mode and if the library call would have set a status
flag, I need the flag to be set.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Question<o:p></o:p></p>
<p class="MsoNormal">My question is, can/should I just rely on
the front end setting the “nobuiltin” attribute for the call
site in any location where the FP behavior needs to be
restricted?</p>
</div>
</blockquote>
<br>
Unless you want to assume that the frontend knows about all
functions that backend knows about, which I don't think we do, I
think this will essentially mean adding nobuiltin to all calls. This
is what we do if you compile using Clang with -fno-builtin or
-ffreestanding. This will work, although it seems better to have a
dedicated attribute for this. no_fp_opts, no_fp_builtin or whatever.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765C71@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ideally, I would like to be able to
conditionally enable optimizations like constant folding if I
am able to prove that the rounding mode, though dynamic, is
known for the callsite at compile time (the constrained
intrinsics have a mechanism to enable this), but at the moment
I am more concerned about correctness and would be willing to
sacrifice optimizations to get correct behavior. Long term, I
was thinking that maybe I could do something like attach
metadata to indicate rounding mode and exception behavior when
they were known.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is there a better way to do this?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>