<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 20, 2017 at 11:22 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</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"><span class="">
    <p><br>
    </p>
    <div class="m_-1631445917631236237moz-cite-prefix">On 08/20/2017 12:02 PM, Daniel Berlin
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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></span>
    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.<span class=""><br>
    <br></span></div></blockquote><div><br></div><div>(and we're looking into using it to do just that :P)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <blockquote 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></span>
    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></div></blockquote><div><br></div><div>That actually sounds very reasonable to me, if we can make it work.</div><div><br></div><div><br></div></div></div></div>