<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 class="im"><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>