<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 08/17/2017 04:49 PM, Daniel Berlin
      via llvm-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CAF4BwTXifivm4E7hPoo1P+DGMPJM9pkDeFUKMF8W1+UsvvsoOQ@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              <br>
              For two given access sequences we can determine if the
              accessed<br>
              objects are allowed to overlap by the rules of the input<br>
              language.</blockquote>
            <div><br>
            </div>
            <div>Sadly, this is where this becomes "unlikely to want to
              use to replace TBAA", at least for me. It may still be a
              thing we want anyway.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    The rules proposed by Ivan for handling C/C++ seem pretty generic.
    We generally explain our current TBAA rules by saying that they're
    generic but motivated by C/C++ rules. I could say the same thing
    about this proposed system with its proposed rules.<br>
    <br>
    <blockquote
cite="mid:CAF4BwTXifivm4E7hPoo1P+DGMPJM9pkDeFUKMF8W1+UsvvsoOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>This scheme is really an encoding of C/C++ TBAA info so
              it can be read by LLVM and requires that *LLVM* have some
              set of rules that it enforces about that scheme.</div>
            <div>But that scheme is still very language specific in how
              it is used.</div>
            <div>GCC still has something in between this and LLVM, where
              the language rules are a bit encoded (but not as much as
              you have).<br>
            </div>
            <div><br>
            </div>
            <div>We (and gcc) have deliberately avoided such schemes, in
              favor of transforming the info into abstract set trees
              that then tag loads and stores.</div>
            <div><br>
            </div>
            <div>The encoding of "struct path" tbaa, is just a way of
              trading space vs time in that encoding.  We trade walking
              time for the space of transitive closure, etc.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    If the provided statistic of 15% holds up, maybe which way we go in
    this trade-off space doesn't matter much?<br>
    <br>
    <blockquote
cite="mid:CAF4BwTXifivm4E7hPoo1P+DGMPJM9pkDeFUKMF8W1+UsvvsoOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>None of the TBAA in LLVM really has any *real* relation
              to the original type system rules, and that is
              deliberate.  I've argued for years that calling it "TBAA"
              just badly confuses people, and i believe here is a good
              example :)</div>
            <div><br>
            </div>
            <div>So i don't think what you've written can be used to
              replace TBAA.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    So *if* we just take the proposed rules for C/C++ as the rules for
    the scheme in general, I'm not sure this is true. There is an
    isomorphism it seems (we could auto-upgrade even, if we'd like, by
    mapping the current offset value onto the field id of this scheme
    (we'd need to use a different root name, however, so everything
    would remain consistent under LTO)).<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
cite="mid:CAF4BwTXifivm4E7hPoo1P+DGMPJM9pkDeFUKMF8W1+UsvvsoOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>However, i *do* believe it would be useful to further
              optimize C and C++ programs in LLVM by using access paths.</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </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>