<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        color:black;}
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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";
        color:black;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";
        color:black;}
.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 bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">You are right some cases would definitely not be right like undef + Nan -> undef. For 2.0f case I’m not sure either if any bits could be known.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It seems that in general fadd( float undef, float %1) -> float %1 should always be safe and I just checked with latest code this doesn’t happen.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Do you think the right solution would be to add such optimization? Is there any reason why we keep some arithmetic constant expressions while those could always be evaluated as far as I understand (unless it
 uses global pointers)? <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In this example there might be cases where we would be able to propagate undef which could generate better code.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thomas<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [<a href="mailto:llvmdev-bounces@cs.uiuc.edu">mailto:llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Philip Reames<br>
<b>Sent:</b> Tuesday, December 10, 2013 12:56 PM<br>
<b>To:</b> <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
<b>Subject:</b> Re: [LLVMdev] Float undef value propagation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 12/9/13 2:13 PM, Raoux, Thomas F wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Constant propagation pass generates constant expression when undef is used in float instructions instead of propagating the undef value.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">; Function Attrs: nounwind<o:p></o:p></p>
<p class="MsoNormal">define float @_Z1fv() #0 {<o:p></o:p></p>
<p class="MsoNormal">entry:<o:p></o:p></p>
<p class="MsoNormal">  %add = fadd fast float undef, 2.000000e+00<o:p></o:p></p>
<p class="MsoNormal">  ret float %add<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Becomes:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">; Function Attrs: nounwind<o:p></o:p></p>
<p class="MsoNormal">define float @_Z1fv() #0 {<o:p></o:p></p>
<p class="MsoNormal">entry:<o:p></o:p></p>
<p class="MsoNormal">  ret float fadd (float undef, float 2.000000e+00)<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Is it safe to transform “%add = fadd fast float undef, 2.000000e+00” to “undef”? Is there a reason why constant propagation pass doesn’t do this transformation?<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">I'm not totally sure this is safe.  Not saying it isn't, but the wording around undef and bit patterns in the language spec is concerning me.  Could there be a case where
 some bit of the result is known given only one constant argument?  I'm not familiar enough with the floating point semantics of LLVM's IR, but suspect there might be such a case.  A few cases worth thinking about: undef + max_float, undef + NAN (signaling
 or non-signalling).  If someone more familiar with floating point knows better, please feel free to chime in. 
<br>
<br>
On the other hand, the following transformation is definitely safe:<o:p></o:p></span></p>
<p class="MsoNormal">define float @_Z1fv() #0 {<o:p></o:p></p>
<p class="MsoNormal">entry:<o:p></o:p></p>
<p class="MsoNormal">  ret 2.000000e+00<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">}<br>
(undef could be zero, thus result of the add is the second argument)<br>
<br>
If we don't apply that transform, we probably should.  (Well, assuming there's not some normalization/rounding trap here.   I don't *think* there is, but I'm not totally sure.)<br>
<br>
Yours,<br>
Philip<br>
 <o:p></o:p></span></p>
</div>
</body>
</html>