<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 10/01/2017 06:05 PM, Sanjay Patel
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+wODit3V6o25V9BUfw_EjOSJf3_ALZfgeriEg2bHYqb70+A0g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div>Are we confident that we just need those 7 bits to
          represent all of the relaxed FP states that we need/want to
          support? <br>
        </div>
        <div><br>
        </div>
        <div>I'm asking because FMF in IR is currently mapped onto the
          SubclassOptionalData of Value...and we have exactly 7 bits
          there. :)<br>
          <br>
        </div>
        If we're redoing the definitions, I'm wondering if we can share
        the struct with the backend's SDNodeFlags, but that already has
        one extra bit for vector reduction. Should we give up on
        SubclassOptionalData for FMF? We have a MD_fpmath enum value for
        metadata, so we could move things over there?<br>
      </div>
    </blockquote>
    <br>
    I agree that using SubclassOptionalData is going to be problematic
    when we run out of bits. As I recall, the reason that we didn't use
    metadata in the first place was because metadata is (generically)
    expensive. This case is very much like the case of debug info: in
    some modes, we add the debugging metadata to nearly every
    instruction. We use metadata for debug locations, syntactically, but
    we actually have a DebugLoc in each instruction that's used for the
    underlying representation. Here we'd have a similar problem: in some
    modes, we'd add this metadata to a large subset of all instructions.
    That could measurably slow down the optimizer. We may need to find
    some other place to put the data (e.g., an actual member variable of
    Instruction or more tail-allocated data in places)<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
cite="mid:CA+wODit3V6o25V9BUfw_EjOSJf3_ALZfgeriEg2bHYqb70+A0g@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Sep 29, 2017 at 8:16 PM,
          Ristow, Warren via llvm-dev <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hal,<br>
            <span class=""><br>
              >> 4. To fix this, I think that additional
              fast-math-flags are likely<br>
              >> needed in the IR.  Instead of the following set:<br>
              >><br>
              >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'<br>
              >><br>
              >> something like this:<br>
              >><br>
              >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +
              'arcp' + 'contract'<br>
              >><br>
              >> would be more useful.  Related to this, the
              current 'fast' flag which acts<br>
              >> as an umbrella (enabling 'nnan' + 'ninf' + 'nsz'
              + 'arcp' + 'contract') may<br>
              >> not be needed.  A discussion on this point was
              raised last November on the<br>
              >> mailing list:<br>
              >><br>
              >> <a moz-do-not-send="true"
href="http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html"
                rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>November/107104.html</a><br>
              ><br>
              > I agree. I'm happy to help review the patches. It
              will be best to have<br>
              > only the finer-grained flags where there's no "fast"
              flag that implies<br>
              > all of the others.<br>
              <br>
            </span>Thanks for the quick response, and for the
            willingness to review.  I won't let<br>
            this languish so long, like the post from last November.<br>
            <br>
            Happy to hear that you feel it's best not to have the
            umbrella "fast" flag.<br>
            <br>
            Thanks again,<br>
            <div class="HOEnZb">
              <div class="h5">-Warren<br>
                ______________________________<wbr>_________________<br>
                LLVM Developers mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                  rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>