<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;}
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.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Courier New";
color:#44546A;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Serge Pavlov <sepavloff@gmail.com> <br>
<b>Sent:</b> Tuesday, January 07, 2020 1:02 PM<br>
<b>To:</b> LLVM Developers <llvm-dev@lists.llvm.org>; Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Cc:</b> Kevin Neal <Kevin.Neal@sas.com><br>
<b>Subject:</b> Calling function from non-default floating-point environment<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p style="margin-left:.5in"><b><i><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:red">EXTERNAL</span></i></b><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:red">
</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Hi all,<br>
<br>
Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if a function is called inside a region where FP environment differs from the default? If the function expects default FP mode it may work incorrectly in such case.<br>
<br>
The C2x standard draft (<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2454.pdf&data=02%7C01%7Ckevin.neal%40sas.com%7Ca580fda4e7484c2bfbe908d7939bbfd8%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637140170280825183&sdata=v5ZXB4G0YpXBdzFvgsJhc1vIHa6cCO2vvasaM%2B3xkvQ%3D&reserved=0">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf</a>)
states (7.6p4):<o:p></o:p></p>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">Certain programming conventions support the intended model of use for the dynamic floating-point environment:*)<br>
— a function call does not alter its caller’s floating-point control modes, clear its caller’s floating point status flags, nor depend on the state of its caller’s floating-point status flags unless the function is so documented;<br>
— a function call is assumed to require default floating-point control modes, unless its documentation promises otherwise;<br>
— a function call is assumed to have the potential for raising floating-point exceptions, unless its documentation promises otherwise.<br>
*) With these conventions, a programmer can safely assume default floating-point control modes (or be unaware of them). The responsibilities associated with accessing the floating-point environment fall on the programmer or program that does so explicitly.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">Right here it says that dealing with non-default modes is the job of the program or programmer: “</span>The responsibilities associated with accessing the floating-point environment
fall on the programmer or program that does so explicitly.<span style="font-family:"Courier New";color:#44546A">” It doesn’t say compiler. It also hedges with words like “certain ... conventions”. If only some conventions then that implies that there are other
conventions that do things differently and that’s OK.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">It explicitly calls out the programmer to solve these issues when opting in to non-default FP behavior.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">And I say this from a company that always runs with traps enabled and therefore has to deal with these FP issues. Sometimes we work around traps in third party, default FP environment
software. Sometimes we _<i>want</i>_ that trap from default FP environment software because it indicates a bug somewhere. We have to examine these cases individually and determine what we need. It’s not the compiler’s job to protect us from ourselves.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">Can we get a language lawyer to settle this once and for all?
<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><br>
It looks like that the standard requires to call functions in default FP mode, so inside a block where #pragma STDC FENV_ACCESS acts, each function call should be converted into sequence:<br>
- store FP state,<br>
- set default FP state,<br>
- call the function,<br>
- restore FP state.<br>
These save/restore instructions could be inserted by compiler. This could be the safest solution but it complicates implementation and may impact performance. There is also another viewpoint: it is user responsibility to provide necessary environment and save/restore
operations must be inserted manually.<br>
<br>
Choosing the proper way we need to take into account:<br>
- generally it is hard for a user to be sure that a function do not depend on FP environment. Functions that apparently do not use FP numbers (like addition to hash table) may actually involve FP operations internally.<br>
- function inlining occurs in IR level and the chosen solution may potentially affect semantics of other languages (maybe Fortran?).<br>
<br>
So the first question is: should the compiler set default FP state prior to function calls?<br>
<br>
<span style="color:#44546A"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">No.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
The next question is: should the compiler support some frontend attribute to mark functions that do not require default FP mode? These are functions that:<br>
- do not involve FP operations,<br>
- work correctly in any FP mode,<br>
- expects particular FP mode,<br>
- modifies FP mode,<br>
- probably something else.<br>
For such functions compiler would not generate save/restore operations. We also could have several attributes if we need to distinguish between these cases.
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">No, the compiler should not be inserting save/restore operations. If this was intended then attributes or keywords would have been introduced a long time ago I bet.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Thanks,<br>
--Serge<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>