<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Yes, exactly; the difference is that
every use has to use the same value, like freeze from the
freeze/poison proposal.<br>
<br>
-Eli<br>
<br>
On 2/28/2018 3:29 PM, Kaylor, Andrew wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0983E6C011D2DC4188F8761B533492DE82542E87@ORSMSX115.amr.corp.intel.com">
<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">For
the first part of Sanjay’s question, I think the answer is,
“Yes, we can fold all of these to NaN in the general case.”
For the second part, which the nnan FMF is present, I’m not
sure. The particulars of the semantics of nnan are unclear
to me.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">But
let me explore what Eli is saying. It sounds reasonable, but
I have a question about it.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Suppose
we have the nnan FMF set, and we encounter this:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= fdiv float %x, undef<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If
I’ve understood Eli’s interpretation correctly, any of the
following transformations would be legal and safe:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= 0.0<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= -1.0<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= inf<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= NaN<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">And
so on, covering all possible concrete values, right? Now
suppose I don’t change it at all. Now I might have IR that
looks like this.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%y
= fdiv float %x, undef<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">%z
= fmul float %q, %y<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">At
this point, while working on %z, I could reconsider and say
“If I had transformed the fdiv into ‘%y = 0.0’ I could
optimize this fmul away too.” So at that point I can choose
to do that, right? And in general I can “retroactively”
choose any concrete value that would be convenient for the
next transformation. You see where I’m going with this?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">How
is that different from just folding the fdiv into undef to
begin with? Is it because I can’t choose different values on
different code paths?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
Friedman, Eli [<a class="moz-txt-link-freetext" href="mailto:efriedma@codeaurora.org">mailto:efriedma@codeaurora.org</a>]
<br>
<b>Sent:</b> Wednesday, February 28, 2018 3:07 PM<br>
<b>To:</b> Sanjay Patel <a class="moz-txt-link-rfc2396E" href="mailto:spatel@rotateright.com"><spatel@rotateright.com></a>;
Kaylor, Andrew <a class="moz-txt-link-rfc2396E" href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a><br>
<b>Cc:</b> llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a>;
Nuno Lopes <a class="moz-txt-link-rfc2396E" href="mailto:nunoplopes@sapo.pt"><nunoplopes@sapo.pt></a>; Stephen Canon
<a class="moz-txt-link-rfc2396E" href="mailto:scanon@apple.com"><scanon@apple.com></a>; David Majnemer
<a class="moz-txt-link-rfc2396E" href="mailto:david.majnemer@gmail.com"><david.majnemer@gmail.com></a>; John Regehr
<a class="moz-txt-link-rfc2396E" href="mailto:regehr@cs.utah.edu"><regehr@cs.utah.edu></a>; Sanjoy Das
<a class="moz-txt-link-rfc2396E" href="mailto:sanjoy@playingwithpointers.com"><sanjoy@playingwithpointers.com></a>; Matt Arsenault
<a class="moz-txt-link-rfc2396E" href="mailto:arsenm2@gmail.com"><arsenm2@gmail.com></a>; Kreitzer, David L
<a class="moz-txt-link-rfc2396E" href="mailto:david.l.kreitzer@intel.com"><david.l.kreitzer@intel.com></a><br>
<b>Subject:</b> Re: how to simplify FP ops with an undef
operand?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I'm pretty sure that isn't what nnan is
supposed to mean. If the result of nnan math were undefined
in the sense of "undef", programs using nnan could have
undefined behavior if the result is used in certain ways
which would not be undefined for any actual float value
(e.g. converting the result to a string), which seems like a
surprising result. And I don't think we gain any useful
optimization power from saying we can fold to undef instead
of something else.<br>
<br>
So I think it's supposed to say "the result is not
specified" or something (so an nnan operation which would
produce a nan can instead produce any value that isn't
undef/poison).<br>
<br>
-Eli<br>
<br>
On 2/28/2018 2:45 PM, Sanjay Patel wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Ah, thanks for explaining. So given
that any of these ops will return NaN with a NaN operand,
let's choose the undef operand value to be NaN. That means
we can fold all of these to a NaN constant in the general
case.<br>
<br>
But if we have 'nnan' FMF, then we can fold harder to
undef?<br>
nnan - Allow optimizations to assume the arguments and
result are not NaN. Such optimizations are required to
retain defined behavior over NaNs, but the value of the
result is undefined.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Feb 28, 2018 at 3:25 PM,
Kaylor, Andrew <<a
href="mailto:andrew.kaylor@intel.com" target="_blank"
moz-do-not-send="true">andrew.kaylor@intel.com</a>>
wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">What
I’m saying is that if we have one operand that
is not an undef value then that operand might be
NaN and if it is then the result must be NaN. So
while it may be true that we don’t have a NaN,
it is not true that we definitely do not have a
NaN in the example. This is analogous to the
example in the language reference where it says
“%A = or %X, undef” -> “%A = undef” is unsafe
because any bits that are set in %A must be set
in the result. If any floating point operand is
NaN dynamically, then the result must be NaN.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
don’t believe it’s accurate to say that NaN is
“morally equivalent” to undef. There are some
similarities, but the important difference is
that NaN always has well defined behavior with a
specific correct result. There is, perhaps, a
sense in which it is analogous to a poison
value, but for the purposes of reasoning about
the correctness of floating point operations I
think it’s best to be pedantic about treating it
as the specific value that it is.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Finally,
I was pretty sure you knew that fdiv by zero
wasn’t undefined. I just wanted to clarify that
the “?” in your comment was indicating that the
assertion in the language reference was
questionable as opposed to this point being in
any way actually uncertain.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a
name="m_3315512054649835366__MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></a><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Sanjay Patel [mailto:<a
href="mailto:spatel@rotateright.com"
target="_blank" moz-do-not-send="true">spatel@rotateright.com</a>]
<br>
<b>Sent:</b> Wednesday, February 28, 2018 1:05
PM<br>
<b>To:</b> Kaylor, Andrew <<a
href="mailto:andrew.kaylor@intel.com"
target="_blank" moz-do-not-send="true">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b> llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>;
Nuno Lopes <<a
href="mailto:nunoplopes@sapo.pt"
target="_blank" moz-do-not-send="true">nunoplopes@sapo.pt</a>>;
Stephen Canon <<a
href="mailto:scanon@apple.com" target="_blank"
moz-do-not-send="true">scanon@apple.com</a>>;
David Majnemer <<a
href="mailto:david.majnemer@gmail.com"
target="_blank" moz-do-not-send="true">david.majnemer@gmail.com</a>>;
John Regehr <<a
href="mailto:regehr@cs.utah.edu"
target="_blank" moz-do-not-send="true">regehr@cs.utah.edu</a>>;
Sanjoy Das <<a
href="mailto:sanjoy@playingwithpointers.com"
target="_blank" moz-do-not-send="true">sanjoy@playingwithpointers.com</a>>;
Friedman, Eli <<a
href="mailto:efriedma@codeaurora.org"
target="_blank" moz-do-not-send="true">efriedma@codeaurora.org</a>>;
Matt Arsenault <<a
href="mailto:arsenm2@gmail.com"
target="_blank" moz-do-not-send="true">arsenm2@gmail.com</a>>;
Kreitzer, David L <<a
href="mailto:david.l.kreitzer@intel.com"
target="_blank" moz-do-not-send="true">david.l.kreitzer@intel.com</a>></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: how to simplify FP ops
with an undef operand?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Correct
- NaN is not undef in IR. But we don't
have a NaN in this example. We have its
moral equivalent in LLVM - an
uninitialized value, undef.
<br>
<br>
So we're not introducing any extra
uncertainty by propagating the undef. The
backend can choose whatever encoding of
undef makes sense when lowering?<o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">And
yes, I don't know why FP-div-by-zero would
ever be UB. I think that text in the LangRef
should be removed regardless of any other
outcome here.<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Wed, Feb 28, 2018 at 1:18 PM,
Kaylor, Andrew <<a
href="mailto:andrew.kaylor@intel.com"
target="_blank"
moz-do-not-send="true">andrew.kaylor@intel.com</a>>
wrote:<o:p></o:p></p>
<blockquote
style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Why
is NaN “just ‘undef’ in IR”?
NaN is a specific value with
well-defined behavior. I
would think that unless the
no-NaNs flag is used we need
to preserve the behavior of
NaNs.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Sanjay Patel [mailto:<a
href="mailto:spatel@rotateright.com"
target="_blank"
moz-do-not-send="true">spatel@rotateright.com</a>]
<br>
<b>Sent:</b> Wednesday,
February 28, 2018 12:08 PM<br>
<b>To:</b> Kaylor, Andrew
<<a
href="mailto:andrew.kaylor@intel.com"
target="_blank"
moz-do-not-send="true">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b> llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>;
Nuno Lopes <<a
href="mailto:nunoplopes@sapo.pt"
target="_blank"
moz-do-not-send="true">nunoplopes@sapo.pt</a>>;
Stephen Canon <<a
href="mailto:scanon@apple.com"
target="_blank"
moz-do-not-send="true">scanon@apple.com</a>>;
David Majnemer <<a
href="mailto:david.majnemer@gmail.com"
target="_blank"
moz-do-not-send="true">david.majnemer@gmail.com</a>>;
John Regehr <<a
href="mailto:regehr@cs.utah.edu"
target="_blank"
moz-do-not-send="true">regehr@cs.utah.edu</a>>;
Sanjoy Das <<a
href="mailto:sanjoy@playingwithpointers.com"
target="_blank"
moz-do-not-send="true">sanjoy@playingwithpointers.com</a>>;
Friedman, Eli <<a
href="mailto:efriedma@codeaurora.org"
target="_blank"
moz-do-not-send="true">efriedma@codeaurora.org</a>>;
Matt Arsenault <<a
href="mailto:arsenm2@gmail.com"
target="_blank"
moz-do-not-send="true">arsenm2@gmail.com</a>><br>
<b>Subject:</b> Re: how to
simplify FP ops with an
undef operand?</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Yes, if %x is
a NaN, we should
expect that NaN
is propagated.
<br>
<br>
I'm still not
sure what to do
here. We can
take comfort in
knowing that
whatever we do
is likely an
improvement over
the current
situation
though. :)<o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">That's
because the code
in InstSimplify is
inconsistent with
the LangRef:<br>
<a
href="http://llvm.org/docs/LangRef.html#undefined-values"
target="_blank"
moz-do-not-send="true">http://llvm.org/docs/LangRef.html#undefined-values</a>
(UB for fdiv by
0?)<o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">...and
both of those are
inconsistent with
undef handling in
SDAG.<o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Let
me propose an
alternate
interpretation:
<br>
<br>
1. The meaning of snan
as written in
IEEE754-2008 is:
"Signaling NaNs afford
representations for
uninitialized
variables..."<br>
2. That matches our
intent with 'undef'
here in IR as written
in the LangRef:
"unspecified
bit-pattern".<br>
3. The current fdiv
transform is actually
correct (any SNaN
UB/trapping commentary
is irrelevant because
we assume exceptions
are off by default).
<br>
<br>
The undef operand
represents an
uninitialized
variable, and the
result of any FP op
with that
uninitialized variable
is well-defined: it's
another NaN which is
just 'undef' in IR.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Feb
28, 2018 at
11:43 AM,
Kaylor, Andrew
<<a
href="mailto:andrew.kaylor@intel.com"
target="_blank" moz-do-not-send="true">andrew.kaylor@intel.com</a>>
wrote:<o:p></o:p></p>
<blockquote
style="border:none;border-left:solid
#CCCCCC
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m
not sure the
transformation
happening with
fdiv is
correct. If we
have “%y =
fdiv float %x,
undef” and %x
is a NaN then
the result
will be NaN
for any value
of the undef,
right? So if I
understand the
undef rules
correctly
(never a
certainty)
then we can’t
safely replace
the expression
with undef. We
could, I
think, replace
it with “%y =
%x” though. I
think the same
is true for
fadd, fsub,
fmul, and
frem.</span><o:p></o:p></p>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Andy</span><o:p></o:p></p>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a
name="m_3315512054649835366_m_-466878842262648"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></a><o:p></o:p></p>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">%y = fadd
float %x,
undef<o:p></o:p></p>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Can we
simplify this?
<br>
<br>
Currently in
IR, we do
nothing for
fadd/fsub/fmul.
For fdiv/frem,
we propagate
undef. The
code comment
for fdiv/frem
says:<br>
"the undef
could be a
snan"<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If that's
correct, then
shouldn't it
be the same
for
fadd/fsub/fmul?
But this can't
be correct
because we
support
targets that
don't raise
exceptions...and
even targets
that raise
exceptions do
not trap by
default on
snan?<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p><o:p> </o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Employee of Qualcomm Innovation Center, Inc.<o:p></o:p></pre>
<pre>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<o:p></o:p></pre>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>