<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
{mso-style-name:x_msonormal;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Thanks, Hal.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hear what you are saying about the accuracy. The problem, from my perspective, is trying to explain to users what they are going to get. The constant folding may be as accurate as the lib call would have been, but it isn’t necessarily
value safe. I’ve been operating on the assumption that LLVM’s FP optimizations are value safe unless fast math flags are used. For the most part that appears to be true. This case breaks my assumption.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I realize that any call to a library function puts claims of value safety on shaky ground, but the standard I’m going for is that you’ll get the same bitwise results compiling at -O0 as you will at -O2 (for instance).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That said, I agree that the difference between constant folding a library call and substituting an approximate calculation is significant. Most users would probably prefer to have this optimization enabled by default. It just leads to a
kind of murky answer to the question of whether or not we’re value safe by default for the users who do care about that.<o:p></o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">I guess what I’m saying is that I do like the idea of a separate flag for this, though as I recall we’re running out of bits for fast math flags. I’m also not sure whether it should be on by default. If we want to permit this transformation
by default, then it shouldn’t be a fast math flag. Probably an attribute on the call site is better? And in that case it feels like we’d be circling back toward “nobuiltin” but can the front end identify which call sites would need that?<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator"></a><b>From:</b> Finkel, Hal J. <hfinkel@anl.gov>
<br>
<b>Sent:</b> Tuesday, April 16, 2019 1:01 PM<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org>; Kaylor, Andrew <andrew.kaylor@intel.com><br>
<b>Subject:</b> Re: [FP] Constant folding math library functions<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Hi, Andy,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">This is somewhat tricky. 'afn' is for approximate functions, to "allow substitution of approximate calculations for functions", but in this case, the answers aren't any more approximate than the
original function calls. Different, but likely no less accurate. This has long caused these kinds of subtle differences when cross compiling, etc. but it's not clear what the best thing to do actually is. Users often want the constant folding, and I've certainly
seen code where the performance depends critically on it, and yet, the compiler will likely never be able to exactly replicate the behavior of whatever libm implementation is used at runtime. Maybe having a dedicated flag to disable just this behavior, aside
from suggesting that users use -fno-builtin=..., would be useful for users who depend on the compiler not folding these kinds of expressions in ways that might differ from their runtime libm behavior?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> -Hal<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div id="Signature">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="3" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Kaylor, Andrew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Sent:</b> Tuesday, April 16, 2019 2:23 PM<br>
<b>To:</b> llvm-dev<br>
<b>Subject:</b> [llvm-dev] [FP] Constant folding math library functions</span> <o:p>
</o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="xmsonormal">Hi everyone,<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">I noticed today that LLVM’s constant folding of math library functions can lead to minor differences in results. A colleague sent me the following test case which demonstrates the issue:<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">#include <stdio.h><o:p></o:p></p>
<p class="xmsonormal">#include <math.h><o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">typedef union {<o:p></o:p></p>
<p class="xmsonormal"> double d;<o:p></o:p></p>
<p class="xmsonormal"> unsigned long long i;<o:p></o:p></p>
<p class="xmsonormal">} my_dbl;<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">int main(void) {<o:p></o:p></p>
<p class="xmsonormal"> my_dbl res, x;<o:p></o:p></p>
<p class="xmsonormal"> x.i = 0x3feeb39556255de2ull;<o:p></o:p></p>
<p class="xmsonormal"> res.d = tanh(x.d);<o:p></o:p></p>
<p class="xmsonormal"> printf("tanh(%f) = %f = %016LX\n", x.d, res.d, res.i);<o:p></o:p></p>
<p class="xmsonormal"> return 0;<o:p></o:p></p>
<p class="xmsonormal">}<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">Compiling with “clang -O2 -g0 -emit-llvm” I get this:<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">define dso_local i32 @main() local_unnamed_addr #0 {<o:p></o:p></p>
<p class="xmsonormal"> %1 = tail call double @tanh(double 0x3FEEB39556255DE2) #2<o:p></o:p></p>
<p class="xmsonormal"> %2 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([24 x i8], [24 x i8]* @.str, i64 0, i64 0),<o:p></o:p></p>
<p class="xmsonormal"> double 0x3FEEB39556255DE2, double 0x3FE7CF009CE7F169,<o:p></o:p></p>
<p class="xmsonormal"> i64 4604876745549017449)<o:p></o:p></p>
<p class="xmsonormal"> ret i32 0<o:p></o:p></p>
<p class="xmsonormal">}<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">We’re still calling ‘tanh’ but all the values passed to printf are constant folded. The constant folding is based on a call to tanh made by the compiler. The problem with this is that if I am linking my program against a different version
of the math library than was used by the compiler I may get a different result.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">I can prevent this constant folding with either the ‘nobuiltin’ or ‘strictfp’ attribute. However, it seems to me like this optimization should really be checking the ‘afn’ fast math flag.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">Opinions?<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">Thanks,<o:p></o:p></p>
<p class="xmsonormal">Andy<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>