<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I've prepared a patch for this change; please feel free to review/comment at <span style="font-family:arial"><a href="http://llvm-reviews.chandlerc.com/D2670">http://llvm-reviews.chandlerc.com/D2670</a></span></div>








</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 10:35 PM, Raul Silvera <span dir="ltr"><<a href="mailto:rsilvera@google.com" target="_blank">rsilvera@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Thank you Philip. I'll prepare a patch and make sure there are proper comments.</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">AFAICT FP env updates are not being modeled at all, and in practice are only implicitly modeled as part of general storage updates. Long term it will be worthwhile to carefully model them, but that's out of the scope of the proposed change.</div>

<div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Cheers,</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 10:30 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I would be perfectly fine with Raul
      & Chandler's proposal, provide that clear documentation is
      added.  The strong distinction between standard library calls and
      intrinsics is an important point for front end authors.  The
      deliberate ignorance of floating point environment flags is
      entirely defensible, but needs to be documented clearly.  We
      should also document which rounding mode (and related bits of FP
      env state) that our optimizations assume.  <br>
      <br>
      Do we currently model flag writes for floating point?  If so, does
      this effect the discussion?<span><font color="#888888"><br>
      <br>
      Philip</font></span><div><div><br>
      <br>
      On 1/24/14 5:19 PM, Raul Silvera wrote:<br>
    </div></div></div><div><div>
    <blockquote type="cite">
      <p dir="ltr">Right. Like Chandler is saying, these intrinsics are
        only used under fno-math-errno and are already properly modeled
        as not modifying errno. </p>
      <p dir="ltr">The change being proposed only affects the dynamic
        change of hardware fp rounding modes, which is not currently
        supported by llvm (#pragma STDC FENV_ACCESS ON). We currently
        appear to be at the worst of both worlds as we do not have
        support for this environment but are always being constrained by
        it. </p>
      <div style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div dir="ltr">
          <div class="gmail_extra"><br>
            <div class="gmail_quote">On Fri, Jan 24, 2014 at 4:17 PM,
              Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                  <div>On 1/24/14 3:52 PM, Raul Silvera wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div class="gmail_default" style="font-family:verdana,sans-serif">In
                        include/llvm/IR/Intrinsics.td there is code to
                        mark sqrt and several other math intrinsics as
                        "ReadOnly", even though they do not read memory.</div>
                      <div class="gmail_default" style="font-family:verdana,sans-serif"><br>
                      </div>
                      <div class="gmail_default" style="font-family:verdana,sans-serif">According
                        to the comments this was done as an attempt to
                        model changes to the FP rounding mode. This is
                        too conservative, and unnecessarily blocks
                        transformations such as commoning and
                        vectorization.</div>
                      <div class="gmail_default" style="font-family:verdana,sans-serif"><br>
                      </div>
                      <div class="gmail_default" style="font-family:verdana,sans-serif">I have
                        heard from others that FP environment changes
                        are not well modeled on LLVM anyway, so perhaps
                        it is appropriate to just change these from
                        ReadOnly to ReadNone. Any opinions on this? If
                        there are no objections I'll prepare a patch.</div>
                    </div>
                  </blockquote>
                </div>
                While our current modeling isn't quite right (e.g. we
                don't model writes to errno and related state), I'm very
                reluctant to see us move in the direction you propose. 
                I'm leary of having intrinsics which are modeled
                incorrectly and relying on the optimizers not to exploit
                that fact and yield incorrect code.  This seems like a
                recipe for disaster long term.</blockquote>
              <div><br>
              </div>
              <div>errno is a totally separate issue. I started to
                confuse these when talking with Raul, and sorry for
                that.</div>
              <div><br>
              </div>
              <div>The intrinsics should (IMO) be modeled as *not*
                fiddling with errno at all. That is already the case
                today, and we don't transform library calls into
                intrinsic calls unless compiling under '-fno-math-errno'
                to explicitly say this is allowed.</div>
              <div><br>
              </div>
              <div>The interesting question is whether the floating
                point intrinsics "read" the hardware rounding mode. I
                would very much like to say "no" because LLVM has
                essentially no support for modeling hardware rounding
                modes in any other context. For example, we don't model
                it for multiply and divide, so modeling it for sqrt
                seems pointless and in impedes a huge number of
                optimizations.</div>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr"><div><font size="4" face="arial black, sans-serif" style="background-color:rgb(0,0,0)" color="#b45f06"> Raúl E. Silvera </font></div>
<div><br></div>
</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><font size="4" face="arial black, sans-serif" style="background-color:rgb(0,0,0)" color="#b45f06"> Raúl E. Silvera </font></div><div><br></div>
</div>
</div>