<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Duncan,<br>
    <br>
    I looked through the IEEE standard and here is what I found:<br>
    <br>
    <b>6.2 Operations with NaNs</b><br>
    <i>"For an operation with quiet NaN inputs, other than maximum and
      minimum operations, if a floating-point result is to be delivered
      the result shall be a quiet NaN which should be one of the input
      NaNs"</i>.<br>
    <br>
    <b>6.2.3 NaN propagation</b><br>
    <i>"An operation that propagates a NaN operand to its result and has
      a single NaN as an input should produce a NaN with the payload of
      the input NaN if representable in the destination format".</i><br>
    <br>
    Floating point add propagates a NaN. There is no conversion in the
    context of LLVM's fadd. So, if %x in "fadd %x, -0.0" is a NaN, the
    result is also a NaN with the same payload.<br>
    <br>
    As regards "fadd %x, undef", where %x might be a NaN and undef might
    be chosen to be (probably some different) NaN, and a possibility to
    fold this to a constant (NaN), the standard says:<br>
    <i>"If two or more inputs are NaN, then the payload of the resulting
      NaN should be identical to the payload of one of the input NaNs if
      representable in the destination format. <b>This standard does
        not specify which of the input NaNs will provide the payload</b>"</i>.<br>
    <br>
    Thus, this makes it possible to fold "fadd %x, undef" to a NaN. Is
    this right?<br>
    <br>
    Oleg<br>
    <br>
    <div class="moz-cite-prefix">On 01.09.2014 10:04, Duncan Sands
      wrote:<br>
    </div>
    <blockquote cite="mid:540444A8.8090501@deepbluecap.com" type="cite">Hi
      Oleg,
      <br>
      <br>
      On 01/09/14 15:42, Oleg Ranevskyy wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        Thank you for your comment, Owen.
        <br>
        My LLVM expertise is certainly not enough to make such decisions
        yet.
        <br>
        Duncan, do you have any comments on this or do you know anyone
        else who can
        <br>
        decide about preserving NaN payloads?
        <br>
      </blockquote>
      <br>
      my take is that the first thing to do is to see what the IEEE
      standard says about NaNs.  Consider for example "fadd x, -0.0". 
      Does the standard specify the exact NaN bit pattern produced as
      output when a particular NaN x is input?  Or does it just say that
      the output is a NaN?  If the standard doesn't care exactly which
      NaN is output, I think it is reasonable for LLVM to assume it is
      whatever NaN is most convenient for LLVM; in this case that means
      using x itself as the output.
      <br>
      <br>
      However this approach does implicitly mean that we may end up not
      folding floating point operations completely deterministically:
      depending on the optimization that kicks in, in one case we might
      fold to NaN A, and in some different optimization we might fold
      the same expression to NaN B.  I think this is pretty reasonable,
      but it is something to be aware of.
      <br>
      <br>
      Ciao, Duncan.
      <br>
    </blockquote>
    <br>
  </body>
</html>