<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Oleg,<br>
      <br>
      What is the status on this? <br>
      Did you move on with a patch?<br>
      <br>
      See also below:<br>
      <br>
      On 9/23/14 8:32 AM, Oleg Ranevskyy wrote:<br>
    </div>
    <blockquote cite="mid:54219274.2030405@gmail.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      Hi Duncan,<br>
      <br>
      <div class="moz-cite-prefix">On 23.09.2014 17:58, Duncan Sands
        wrote:<br>
      </div>
      <blockquote cite="mid:54217C76.3020001@deepbluecap.com"
        type="cite">Hi Oleg, <br>
        <br>
        On 22/09/14 17:56, Oleg Ranevskyy wrote: <br>
        <blockquote type="cite">Hi Duncan, <br>
          <br>
          On 17.09.2014 21:10, Duncan Sands wrote: <br>
          <blockquote type="cite">Hi Oleg, <br>
            <br>
            On 17/09/14 18:45, Oleg Ranevskyy wrote: <br>
            <blockquote type="cite">Hi, <br>
              <br>
              Thank you for all your helpful comments. <br>
              <br>
              To sum up, below is the list of correct folding examples
              for fadd: <br>
                      (1)  fadd %x, -0.0            ->     %x <br>
                      (2)  fadd undef, undef    ->     undef <br>
                      (3)  fadd %x, undef         ->     NaN  (undef
              is a NaN which is <br>
              propagated) <br>
              <br>
              Looking through the code I found the "NoNaNs" flag
              accessed through an instance <br>
              of the FastMathFlags class. <br>
              (2) and (3) should probably depend on it. <br>
              If the flag is set, (2) and (3) cannot be folded as there
              are no NaNs and we are <br>
              not guaranteed to get an arbitrary bit pattern from fadd,
              right? <br>
            </blockquote>
            <br>
            I think it's exactly the other way round: if NoNans is set
            then you can fold <br>
            (2) and (3) to undef.  That's because (IIRC) the NoNans flag
            promises that no <br>
            NaNs will be used by the program. However "undef" could be a
            NaN, thus the <br>
            promise is broken, meaning the program is performing
            undefined behaviour, and <br>
            you can do whatever you want. <br>
          </blockquote>
          Oh, I see the point now. I thought if NoNaNs was set then no
          NaNs were possible <br>
          at all. But undef is still an arbitrary bit pattern that might
          occasionally be <br>
          the same as the one of a NaN. Thank you for the explanation. <br>
          <br>
          Thus, "fadd/fsub/fmul/fdiv undef, undef" can always be folded
          to undef, whereas <br>
          "fadd/fsub/fmul/fdiv %x, undef" is folded to either undef
          (NoNaNs is set) or a <br>
          NaN (NoNaNs is not set). <br>
        </blockquote>
        <br>
        for fmul and fdiv, the reasoning does depend on fmul %x, 1.0
        always being equal to %x (likewise: fdiv %x, 1.0 being equal to
        %x).  Is this true? <br>
      </blockquote>
      Do you mean that we can't apply "fmul/fdiv undef, undef" to undef
      folding if "fmul/fdiv %x, 1.0" is not guaranteed to be %x?<br>
      If we choose one undef to have an arbitrary bit pattern and
      another undef = 1.0, we need a guarantee to get the bit pattern of
      the first undef. Do I get it right?<br>
    </blockquote>
    I don't think so. I don't think it makes no sense to try to think
    about each individual case like that. <br>
    If you consider returning an undef, I believe the question is "can
    you form all the possible bit pattern that the undef represents from
    the expression?"<br>
    <br>
    if you have:  <br>
      op float undef, undef <br>
    <br>
    then, since the inputs are unconstrained, the question is can "op"
    form any possible float value as an output?<br>
    If yes then folding to undef is valid.<br>
    <br>
    For instance fabs(undef) can't fold to undef because the possible
    range of output is larger that what fabs can produce.<br>
    <br>
    -- <br>
    Mehdi<br>
    <br>
    <br>
    <blockquote cite="mid:54219274.2030405@gmail.com" type="cite"> <br>
      I checked the standard regarding "x*1.0 == x" and found that only
      "10.4 Literal meaning and value-changing optimizations" addresses
      this. I don't pretend to thoroughly understand this paragraph yet,
      but it seems to me that language standards are  required to
      preserve the literal meaning of the source code. Applying the
      identity property x*1 is a part of this. Here is a quote from
      IEEE-754:<br>
      <br>
      <i>"The following value-changing transformations, among others,
        preserve the literal meaning of the source</i><i><br>
      </i><i>code:</i><i><br>
      </i><i>― Applying the identity property 0 + x when x is not zero
        and is not a signaling NaN and the result</i><i><br>
      </i><i>has the same exponent as x.</i><i><br>
      </i><i>― Applying the identity property 1 × x when x is not a
        signaling NaN and the result has the same</i><i><br>
      </i><i>exponent as x."</i><i><br>
      </i><i><br>
      </i>Maybe Owen or Stephen would be able to clarify this.<br>
      <br>
      Thank you.<br>
      Oleg<br>
      <blockquote cite="mid:54217C76.3020001@deepbluecap.com"
        type="cite"> <br>
        Ciao, Duncan. <br>
        <br>
        <blockquote type="cite"> <br>
          Oleg <br>
          <blockquote type="cite"> <br>
            <blockquote type="cite"> <br>
              Other arithmetic FP operations (fsub, fmul, fdiv) also
              propagate NaNs. Thus, the <br>
              same rules seem applicable to them as well: <br>
              ---------------------------------------------------------------------

              <br>
              - fdiv: <br>
                      (4) "fdiv %x, undef" is now folded to undef. <br>
            </blockquote>
            <br>
            But should be folded to NaN, not undef. <br>
            <br>
            <blockquote type="cite">        The code comment states this
              is done because undef might be a sNaN. We <br>
              can't rely on sNaNs as they can either be masked or the
              platform might not have <br>
              FP exceptions at all. Nevertheless, such folding is still
              correct due to the NaN <br>
              propagation rules we found in the Standard - undef might
              be chosen to be a NaN <br>
              and its payload will be propagated. <br>
                      Moreover, this looks similar to (3) and can be
              folded to a NaN. /Is it <br>
              worth doing?/ <br>
            </blockquote>
            <br>
            As the current folding to undef is wrong, it has to be
            fixed. <br>
            <br>
            <blockquote type="cite"> <br>
                      (5) fdiv undef, undef    ->    undef <br>
            </blockquote>
            <br>
            Yup. <br>
            <br>
            <blockquote type="cite">---------------------------------------------------------------------

              <br>
              - fmul: <br>
                      (6) fmul undef, undef    ->    undef <br>
            </blockquote>
            <br>
            Yup. <br>
            <br>
            <blockquote type="cite">        (7) fmul %x, undef       
              -> NaN or undef (undef is a NaN, which is <br>
              propagated) <br>
            </blockquote>
            <br>
            Should be folded to NaN, not undef. <br>
            <br>
            <blockquote type="cite">---------------------------------------------------------------------

              <br>
              - fsub: <br>
                      (8) fsub %x, -0.0           ->    %x  (if %x is
              not -0.0; works this way <br>
              now) <br>
            </blockquote>
            <br>
            Should this be: fsub %x, +0.0 ? <br>
          </blockquote>
          fsub %x, +0.0 is also covered and always folded to %x. <br>
          The version with -0.0 is similar except it additionally checks
          if %x is not -0.0. <br>
          <blockquote type="cite"> <br>
            <blockquote type="cite">        (9) fsub %x, undef       
              -> NaN or undef (undef is a NaN, which is <br>
              propagated) <br>
            </blockquote>
            <br>
            Should fold to NaN not undef. <br>
            <br>
            <blockquote type="cite">      (10) fsub undef, undef   ->
              undef <br>
            </blockquote>
            <br>
            Yup. <br>
            <br>
            Ciao, Duncan. <br>
            <br>
            <blockquote type="cite">---------------------------------------------------------------------

              <br>
              <br>
              I will be very thankful if you could review this final
              summary and share your <br>
              thoughts. <br>
              <br>
              Thank you. <br>
              <br>
              P.S. Sorry for bothering you again and again. <br>
              Just want to make sure I clearly understand the subject in
              order to make correct <br>
              code changes and to be able to help others with this in
              the future. <br>
              <br>
              Kind regards, <br>
              Oleg <br>
              <br>
              On 16.09.2014 21:42, Duncan Sands wrote: <br>
              <blockquote type="cite">On 16/09/14 19:37, Owen Anderson
                wrote: <br>
                <blockquote type="cite">As far as I know, LLVM does not
                  try very hard to guarantee constant folded <br>
                  NaN payloads that match exactly what the target would
                  generate. <br>
                </blockquote>
                <br>
                I'm with Owen here.  Unless ARM people object, I think
                it is reasonable to say <br>
                that at the LLVM IR level we may assume that the IEEE
                rules are followed. <br>
                <br>
                Ciao, Duncan. <br>
                <br>
                <blockquote type="cite"> <br>
                  —Owen <br>
                  <br>
                  <blockquote type="cite">On Sep 16, 2014, at 10:30 AM,
                    Oleg Ranevskyy <a moz-do-not-send="true"
                      class="moz-txt-link-rfc2396E"
                      href="mailto:llvm.mail.list@gmail.com"><llvm.mail.list@gmail.com></a>
                    <br>
                    wrote: <br>
                    <br>
                    Hi Duncan, <br>
                    <br>
                    I reread everything we've discussed so far and would
                    like to pay closer <br>
                    attention to the the ARM's FPSCR register mentioned
                    by Stephen. <br>
                    It's really possible on ARM systems that floating
                    point operations on one or <br>
                    more qNaN operands return a NaN different from the
                    operands. I.e. operand <br>
                    NaN is not propagated. This happens when the
                    "default NaN" flag is set in <br>
                    the FPSCR (floating point status and control
                    register). The result in this <br>
                    case is some default NaN value. <br>
                    <br>
                    This means "fadd %x, -0.0", which is currently
                    folded to %x by <br>
                    InstructionSimplify, might produce a different
                    result if %x is a NaN. This <br>
                    breaks the NaN propagation rules the IEEE standard
                    establishes and <br>
                    significantly reduces folding capabilities for the
                    FP operations. <br>
                    <br>
                    This also applies to "fadd undef, undef" and "fadd
                    %x, undef". We can't rely <br>
                    on getting an arbitrary NaN here on ARMs. <br>
                    <br>
                    Would you be able to confirm this please? <br>
                    <br>
                    Thank you in advance for your time! <br>
                    <br>
                    Kind regards, <br>
                    Oleg <br>
                    <br>
                    On 10.09.2014 22:50, Duncan Sands wrote: <br>
                    <blockquote type="cite">Hi Oleg, <br>
                      <br>
                      On 01/09/14 18:46, Oleg Ranevskyy wrote: <br>
                      <blockquote type="cite">Hi Duncan, <br>
                        <br>
                        I looked through the IEEE standard and here is
                        what I found: <br>
                        <br>
                        *6.2 Operations with NaNs* <br>
                        /"For an operation with quiet NaN inputs, other
                        than maximum and minimum <br>
                        operations, if a floating-point result is to be
                        delivered the result shall <br>
                        be a <br>
                        quiet NaN which should be one of the input
                        NaNs"/. <br>
                        <br>
                        *6.2.3 NaN propagation* <br>
                        /"An operation that propagates a NaN operand to
                        its result and has a <br>
                        single NaN <br>
                        as an input should produce a NaN with the
                        payload of the input NaN if <br>
                        representable in the destination format"./ <br>
                      </blockquote>
                      <br>
                      thanks for finding this out. <br>
                      <br>
                      <blockquote type="cite"> <br>
                        Floating point add propagates a NaN. There is no
                        conversion in the <br>
                        context of <br>
                        LLVM's fadd. So, if %x in "fadd %x, -0.0" is a
                        NaN, the result is also a <br>
                        NaN <br>
                        with the same payload. <br>
                      </blockquote>
                      <br>
                      Yes, folding "fadd %x, -0.0" to "%x" is correct. 
                      This implies that "fadd <br>
                      undef, undef" can be folded to "undef". <br>
                      <br>
                      <blockquote type="cite"> <br>
                        As regards "fadd %x, undef", where %x might be a
                        NaN and undef might be <br>
                        chosen <br>
                        to be (probably some different) NaN, and a
                        possibility to fold this to a <br>
                        constant (NaN), the standard says: <br>
                        /"If two or more inputs are NaN, then the
                        payload of the resulting NaN <br>
                        should be <br>
                        identical to the payload of one of the input
                        NaNs if representable in the <br>
                        destination format. *This standard does not
                        specify which of the input <br>
                        NaNs will <br>
                        provide the payload*"/. <br>
                        <br>
                        Thus, this makes it possible to fold "fadd %x,
                        undef" to a NaN. Is this <br>
                        right? <br>
                      </blockquote>
                      <br>
                      Yes, I agree. <br>
                      <br>
                      Ciao, Duncan. <br>
                      <br>
                      <blockquote type="cite"> <br>
                        Oleg <br>
                        <br>
                        On 01.09.2014 10:04, Duncan Sands wrote: <br>
                        <blockquote 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 <br>
                            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 <br>
                          says <br>
                          about NaNs.  Consider for example "fadd x,
                          -0.0". Does the standard <br>
                          specify <br>
                          the exact NaN bit pattern produced as output
                          when a particular NaN x is <br>
                          input?  Or does it just say that the output is
                          a NaN? If the standard <br>
                          doesn't <br>
                          care exactly which NaN is output, I think it
                          is reasonable for LLVM to <br>
                          assume <br>
                          it is whatever NaN is most convenient for
                          LLVM; in this case that means <br>
                          using <br>
                          x itself as the output. <br>
                          <br>
                          However this approach does implicitly mean
                          that we may end up not folding <br>
                          floating point operations completely
                          deterministically: depending on the <br>
                          optimization that kicks in, in one case we
                          might fold to NaN A, and in <br>
                          some <br>
                          different optimization we might fold the same
                          expression to NaN B.  I <br>
                          think <br>
                          this is pretty reasonable, but it is something
                          to be aware of. <br>
                          <br>
                          Ciao, Duncan. <br>
                        </blockquote>
                        <br>
                      </blockquote>
                      <br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                </blockquote>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>