<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>It'd be great if we can get all of this properly documented in
the LangRef - we often seem to be relying on comments next to the
individual combines to guide us in many of these cases.<br>
</p>
<p>If we're going to be using isKnownNeverNaN to support this - the
SelectionDAG version needs a bit of improvement for better vector
handling etc. to match the ValueTracking version.<br>
</p>
<br>
<div class="moz-cite-prefix">On 28/02/2018 22:45, Sanjay Patel via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+wODitVf30vPW7-_JWS6K+0O0BBmBmRumc195+m-6XDuOsJwQ@mail.gmail.com">
<div dir="ltr">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.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 28, 2018 at 3:25 PM,
Kaylor, Andrew <span dir="ltr"><<a
href="mailto:andrew.kaylor@intel.com" target="_blank"
moz-do-not-send="true">andrew.kaylor@intel.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_3315512054649835366WordSection1">
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><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><wbr>]
<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.<wbr>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></p>
<div>
<div class="h5"><br>
<b>Subject:</b> Re: how to simplify FP ops with an
undef operand?</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal"
style="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?</p>
</div>
<p class="MsoNormal">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.</p>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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:</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"><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></p>
<p class="MsoNormal"><a
name="m_3315512054649835366_m_-4668788422626485428__MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></a></p>
<p class="MsoNormal"><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><wbr>]
<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.<wbr>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></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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. :)</p>
</div>
<p class="MsoNormal">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.<wbr>html#undefined-values</a>
(UB for fdiv by 0?)</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">...and
both of those are
inconsistent with undef
handling in SDAG.</p>
</div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">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:</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"><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></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-Andy</span></p>
<p
class="MsoNormal"><a
name="m_3315512054649835366_m_-4668788422626485428_m_-49180089321786"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></a></p>
<p
class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">%y
= fadd float
%x, undef</p>
</div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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"</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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?</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>