<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I agree with Ulrich. The default behavior of LLVM IR is to assume that the roundToNearest is the current rounding mode everywhere. This corresponds to the C standard, which says that the user may only modify the floating point environment
if fenv access is enabled. In the latest version of the C standard, pragmas are added which can change the rounding mode for a region, and if these are implemented in clang the constrained versions of all FP operations should be used. However, outside of regions
where fenv access is enabled either by pragma or command line option, we are free to assume that the current rounding mode is the default rounding mode.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, llvm.rint and llvm.nearbyint (the non-constrained versions) can be specifically documented as performing their operation according to roundToNearest and clang can use them in the default case for the corresponding libm functions, and
llvm.experimental.constrained.rint and llvm.experimental.constrained.nearbyint can be documented as using the current rounding mode.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The only issue I see is that since we also assume FP operations have no side effects by default there is no difference between llvm.rint and llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint completely.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As for the target-specific intrinsics, you are correct that we need a plan for that. I have given it some thought, but nothing is currently implemented. My suggestion would be that we should set the strictfp attribute on these intrinsics
and provide the rounding mode and exception behavior arguments using an operand bundle. We do still need some way to handle the side effects. My suggestion here is to add some new attribute that means “no side effects” in the absence of the strictfp attribute
and something similar to “inaccessibleMemOnly” in the presence of strictfp.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We could make the new attribute less restrictive than inaccessibleMemOnly in that it only really needs to act as a barrier relative to other things that are accessing the fp environment. I believe Ulrich suggested this to me at the last
LLVM Developer Meeting.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Serge Pavlov <sepavloff@gmail.com> <br>
<b>Sent:</b> Monday, March 02, 2020 8:10 AM<br>
<b>To:</b> Ulrich Weigand <Ulrich.Weigand@de.ibm.com><br>
<b>Cc:</b> Kaylor, Andrew <andrew.kaylor@intel.com>; Cameron McInally <cameron.mcinally@nyu.edu>; Kevin Neal <kevin.neal@sas.com>; LLVM Developers <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: Should rint and nearbyint be always constrained?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I'm not sure why this is an issue. Yes, these two intrinsics depend<br>
on the current rounding mode according to the C standard, and yes,<br>
LLVM in default mode assumes that the current rounding mode is the<br>
default rounding mode. But the same holds true for many other<br>
intrinsics and even the arithmetic IR operations like add.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Any other intrinsic, like `floor`, `round` etc has meaning at default rounding mode. But use of `rint` or `nearbyint` in default FP environment is strange, `roundeven` can be used instead. We could use more general intrinsics in all cases,
as the special case of default environment is not of practical interest.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There is another reason for special handling. Set of intrinsics includes things like `x86_sse_cvtss2si`. It is unlikely that all of them eventually get constrained counterpart. It looks more natural that such intrinsics are defined as accessing
FP environment and can be optimized if the latter is default. These two intrinsics could be a good model for such cases. IIUC, splitting entities into constrained or non-constrained is a temporary solution, ideally they will merge into one entity. We could
do it for some intrinsics now.<o:p></o:p></p>
<div>
<p class="MsoNormal"> <br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Thanks,<br>
--Serge<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 2, 2020 at 8:58 PM Ulrich Weigand <<a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich.Weigand@de.ibm.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p style="margin-bottom:12.0pt"><tt><span style="font-size:10.0pt">Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote on 02.03.2020 14:38:48:</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>> This approach has issues when applied to the intrinsics `rint` and </tt><br>
<tt>> `nearbyint`. Value returned by either of these intrinsics depends on</tt><br>
<tt>> current rounding mode. If they are considered as operation in </tt><br>
<tt>> default environment, they would round only to nearest. It is by far </tt><br>
<tt>> not the meaning of the standard C functions that these intrinsics represent.</tt><br>
</span><br>
<tt><span style="font-size:10.0pt">I'm not sure why this is an issue. Yes, these two intrinsics depend</span></tt><br>
<tt><span style="font-size:10.0pt">on the current rounding mode according to the C standard, and yes,</span></tt><br>
<tt><span style="font-size:10.0pt">LLVM in default mode assumes that the current rounding mode is the</span></tt><br>
<tt><span style="font-size:10.0pt">default rounding mode. But the same holds true for many other</span></tt><br>
<tt><span style="font-size:10.0pt">intrinsics and even the arithmetic IR operations like add.</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">If you want to stop clang from making the default rounding mode</span></tt><br>
<tt><span style="font-size:10.0pt">assumption, you need to use the -frounding-math option (or one</span></tt><br>
<tt><span style="font-size:10.0pt">of its equivalents), which will cause clang to emit the corresponding</span></tt><br>
<tt><span style="font-size:10.0pt">constrained intrinsics instead, for those two as well all other</span></tt><br>
<tt><span style="font-size:10.0pt">affected intrinsics.</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">I don't see why it would make sense to add another special case</span></tt><br>
<tt><span style="font-size:10.0pt">just for those two intrinsics ...</span></tt><br>
<br>
<br>
<tt><span style="font-size:10.0pt">Bye,</span></tt><br>
<tt><span style="font-size:10.0pt">Ulrich</span></tt><o:p></o:p></p>
</div>
</blockquote>
</div>
</div>
</body>
</html>