<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 6:48 PM, 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"><div><div class="h5">
    <p><br>
    </p>
    <div class="m_7357556789205431870moz-cite-prefix">On 09/03/2017 08:35 PM, Daniel Berlin
      via llvm-commits wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote"><span>
                      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
                        <br>
                        I believe this follows from the
                        GetUnderlyingObject and<br>
                        isIdentifiedObject related logic in 
                        BasicAAResult::aliasCheck.<br>
                        <br>
                        And I'm not aware of any transforms in LLVM
                        today that contradict the<br>
                        pointer aliasing rules.<br>
                      </blockquote>
                      <div><br>
                      </div>
                    </span>
                    <div>I assume you meant "do the wrong thing here".
                      Which i still believe is definitely wrong, FWIW,
                      but i'm too lazy to go searching through bugzilla
                      some more today, so i'm going to let it go.</div>
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div>I'll also point out, you didn't read or write anything
              in your example.</div>
            <div>Which is strange to me because the usual semantic is
              "allowed to alias, but not allowed to be used to
              load/store".</div>
            <div>IE if you ask if the two pointers alias, the answer is
              yes.</div>
            <div>If you ask if a load can touch a given store, the
              answer is no.</div>
            <div><br>
            </div>
            <div>Here you are saying the pointer aliasing rules apply
              even to unwritten/unread pointers.</div>
            <div>That to me, is ... very strange.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div></div>
    As far as I can tell, LLVM does not support pointer aliasing in the
    abstract. </div></blockquote><div><br></div><div>Right, though i'll point out that applying the aliasing rules when there are no memory accesses makes this very confusing, because it implies you can't even form a pointer to a thing this way, which is *not* what i would have taken away from the section on pointer aliasing from the langref.</div><div><br></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">All queried memory locations are presumed to belong to
    some memory access. We may want to change this at some point.<span class="HOEnZb"><font color="#888888"><br>
    <br></font></span></div></blockquote><div><br></div><div>It is what it is. It does give you a 0% chance of ever being able to use aliasing to help with value equality (there are other issues).</div><div><br></div><div>It also means there are interesting ways to take noalias pointers and turn them into aliasing pointers.  In most higher level languages, the pointers *usually* never stopped aliasing in the first place, it was the loads/stores that didn't conflict.</div><div><br></div><div><br></div></div></div></div>