<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 08/20/2017 12:02 PM, Daniel Berlin
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@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:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                    <div>I do not believe the current proposal will
                      solve all of those cases, particularly when the
                      fields are the same type and structures are
                      compatible but they cannot overlap in C/C++
                      anyway.</div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div>One of the threads is titled "<span
                style="font-size:inherit;font-weight:inherit">[PATCH]
                D20665: Claim NoAlias if two GEPs index different fields
                of the same struct"</span></div>
            <div><br>
            </div>
            <div>For example, given<br>
              <span style="font-size:12.8px">struct {</span><br
                style="font-size:12.8px">
              <span style="font-size:12.8px">  int arr_a[2];</span><br
                style="font-size:12.8px">
              <span style="font-size:12.8px">  int arr_b[2];</span><br
                style="font-size:12.8px">
              <span style="font-size:12.8px">};</span></div>
            <div>assume you cannot see the original allocation site.<br>
            </div>
            <div>in llvm ir gep(arr_b,  -1) is legally an access to
              arr_a[1].</div>
            <div>You can use -1 even though it's going to be a pointer
              to [2 x i32].</div>
            <div>Thus, you can't even tell that gep(arr_a, 0) and
               gep(arr_b, -1) do not overlap without being able to know
              *something* about the layout of fields in the structure
              you are talking about.</div>
            <div><br>
            </div>
            <div>I'd start with: It should not require tbaa to determine
              that loads from geps that arr_a and arr_b cannot overlap.
                It is true regardless of the types involved.</div>
            <div><br>
            </div>
            <div>In terms of "who cares", Google definitely compiles
              with -fno-strict-aliasing (because third party packages
              are still not clean enough), and last i looked, Apple did
              the same (but i admittedly have not kept up).</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    We definitely also have code that we compile that way as well. As it
    turns out, this is my motivation for developing the type sanitizer
    (so we have some tool that users can employ to clean up this kind of
    code). Patches have been posted for review.<br>
    <br>
    <blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div>GCC can definitely disambiguate field accesses (through
              points-to and otherwise) better than LLVM in a situation
              where strict aliasing is off.</div>
            <div><br>
            </div>
            <div>As an aside, i also can't build a sane field-sensitive
              points-to on our current type system, because the types
              and structures are already meaningless  (and we are busy
              making it weaker, too).</div>
            <div>I don't think we are going to want to tie
              field-sensitive points-to to TBAA (you definitely want to
              be able to run the former without the latter), but right
              now that is the only metadata you can use.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    This also brings up a good point. Even if we use the same metadata
    for both type and field analysis, I don't see why we can't disable
    the type portions without disabling the field analysis (essentially
    by emitting everything as one universally-aliasing type). Maybe we
    should do that for -fno-strict-aliasing?<br>
    <br>
    Thanks again,<br>
    Hal<br>
    <br>
    <blockquote
cite="mid:CAF4BwTVhUFRqtWFOLr-d0E1ra+HQ0XArjGq+_AH-HWbf1VNXmw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Finally, the merging of TBAA is definitely going to be
              more conservative than the merging of field offset info:
              If we merge a load of an int and a float, we will, IIRC,
              go to the nearest common ancestor in TBAA.   The field
              offset info may actually still be identical between the
              two, but we will lose it by creating/or going to the
              common ancestor.</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div> </div>
          </div>
          <br>
        </div>
      </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>