<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">>
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Tom is working on a patch which will remove all uses of fpimm operands and replace them with the bitcasted integers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">> which I think will fix this. I think this was actually broken by one of the previous patches in this set that stopped promoting<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">> some float operations to integers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thanks. I didn't spot the commit that fixed it but it's now passing these tests.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Matt Arsenault [mailto:whatmannerofburgeristhis@gmail.com]
<b>On Behalf Of </b>Matt Arsenault<br>
<b>Sent:</b> 06 January 2015 15:26<br>
<b>To:</b> Daniel Sanders<br>
<b>Cc:</b> Matthew P Arsenault; llvm-commits@cs.uiuc.edu<br>
<b>Subject:</b> Re: [llvm] r224458 - R600/SI: Fix f64 inline immediates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jan 3, 2015, at 3:05 PM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">From: Matt Arsenault [<a href="mailto:whatmannerofburgeristhis@gmail.com">whatmannerofburgeristhis@gmail.com</a>] on behalf of Matt Arsenault [<a href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>]<br>
Sent: 02 January 2015 16:24<br>
To: Daniel Sanders<br>
Cc: Matthew P Arsenault; <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
Subject: Re: [llvm] r224458 - R600/SI: Fix f64 inline immediates<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Dec 23, 2014, at 3:09 PM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<br>
<br>
Hi Matt,<br>
<br>
This commit added some tests that fail on the Mips builder. I've had a quick look and I don't understand the failure at the moment. As far as I can tell, add_inline_imm_neg_2_f32 is being given 0xffffffffc0000000 (double precision -NaN) as the immediate input
to the fadd. Somewhere along the lines, the -NaN becomes NaN on this Mips host, and it eventually prints 0x7fbfffff (single precision NaN) for the v_add_f32_e64 instruction. The test is expecting '-2' and works on my x86_64 host.<br>
<br>
I don't understand the R600 targets instruction set so I might be missing something obvious. The main thing I don't understand is that the test provides -NaN as the input but is expected to emit -2 in the output. Could you explain?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Does Mips use a strange value for NaN? I believe in some places the tests for valid inline immediate constants end up using host floating point variables.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
By modern standards, probably yes. Most Mips systems use IEEE754-1985 compliant NaN's but not IEEE754-2008 compliant ones. See below.<br>
<br style="orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">I think the reason it uses -2 is because any value for NaN can be used as long as all of the exponent bits are 1, and the fraction is non-zero. Constants from -16 to 64
are free to use as operands usually, so picking a value that > > satisfies this should work. I’m not sure why exactly it wouldn’t use -1 though. I do not believe I changed how this was represented. I think what I did change was that values that used to be
bitcasted to integers are now floating > point, so later when checking the value it ends up using a host float.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Ah yes, integer -2 is a bitpattern for a single precision NaN. I was thinking the instruction meant -2.0 for some reason.<br>
<br>
I think I know what's going on and I agree that this commit didn't change the behaviour, it merely added a test that was affected by it.<br>
<br>
The definition of NaN you gave above is correct but there are two kinds of NaN, signalling and quiet. IEEE754-1985 didn't specify exactly how they were distinguished but IEEE754-2008 specifies the most significant fraction bit to be an is_quiet flag (1=quiet,
0=signalling). Unfortunately, Mips originally chose a different definition (the same bit but opposite meanings) to the one that 2008 eventually prescribed and as a result we have ended up with two definitions controlled by a hardware config bit. Up until very
recently (Mips32r6/Mips64r6), hardware support for 2008 was optional so most software uses the 1985 definition for compatibility reasons. APFloat uses the 2008 definition.<br>
<br>
The root of the problem is that MCOperand uses the host double type to store target values. This isn't much of a problem by itself but there's also an implicit conversion from float to double in AMDGPUMCInstLower::lower() when it calls MCOperand::CreateFPImm()
for the single precision case. </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">QNaN promoted to double is still QNaN but there's no requirement to preserve any of the sign or fraction bits (except the is_quiet bit). On Mips, this conversion produces
0x7fbfffff which is a QNaN for most Mips systems, but an SNaN according to IEEE754-2008. So the is_quiet bit flips because the host and target disagree on whether it's an is_quiet or an is_signalling bit and the value was promoted by the host. We lost the
sign bit as well because nothing in the standard specifies that the sign bit has to be preserved (because it's meaningless for NaN).<br>
<br>
Presumably the correct fix is to store APFloat's in MCOperand instead of host doubles. That's quite a big change though.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Tom is working on a patch which will remove all uses of fpimm operands and replace them with the bitcasted integers, which I think will fix this. I think this was actually broken by one of the previous patches in this set that stopped promoting
some float operations to integers.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>