<div dir="ltr">(and note: It's not clear GCC agrees with my interpretation. I can get it to seem to answer both ways.  Depending on what i do, and looking at optimizer dumps, i can get it to ignore the access to x->i, and assume it has no effect on b->a, *and* get it to assume it does, and cause reloads of x->i)<div><br></div><div>+Richard in case he has any thoughts.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 19, 2017 at 9:00 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Aug 19, 2017 at 6:29 AM, Ivan A. Kosarev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Daniel, Hal,<br>
<br>
I'm trying to figure out what we would need to do in terms of the current approach, accepting its limitations,</blockquote><div><br></div></span><div>We don't have to accept the limitations?</div><div>We already know it's pretty trivial to extend it, and we aren't against extending it at all.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> to support unions, member arrays, aggregate accesses </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and type identifiers and what I get looks suspiciously simple.</blockquote><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Can you please check it out and let me know if I'm missing something?<br></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br><span class="">
For aggregate accesses:<br>
<br>
The comment in TypeBasedAliasAnalysis.cpp suggests:<br>
<br>
  // TODO: We need to check if AccessType of TagA encloses AccessType of<br>
  // TagB to support aggregate AccessType. If yes, return true.<br>
<br>
Consider these two accesses:<br>
<br>
    struct A { int i; };<br>
    struct B { struct A a; } *b;<br>
<br>
    struct X { int i; } *x;<br>
<br>
    b->a<br>
    x->i<br>
<br>
Following the rule in the comment, the accesses are allowed to overlap, which is wrong.<br></span></blockquote><div><br></div><div>i don't believe this to be wrong in terms of the C/C++ TBAA rules.<br></div><div><br></div><div>C rule:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">An object shall have its stored value accessed only by an lvalue expression that has one of the following types:<ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">a type compatible with the effective type of the object,</li></ul><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">a qualified version of a type compatible with the effective type of the object,</li></ul><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">a type that is the signed or unsigned type corresponding to the effective type of the object,</li></ul><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,</li></ul><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or</li></ul><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(36,39,41)"><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">a character type.</li></ul></blockquote><div><font color="#242729" face="Arial, Helvetica Neue, Helvetica, sans-serif"><span style="font-size:15px"><br></span></font></div></div>This is an aggregate type that includes a type compatible with the effective type of the object.  In particular,</div><div class="gmail_quote">x->i is an lvalue expression of type "int"</div><div class="gmail_quote">b->a is an lvalue expression of type "struct A"</div><div class="gmail_quote">"struct A" is an aggregate type that includes "int" among its members.</div><div class="gmail_quote">Therefore, the b->a object may access x->i by TBAA<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">These rules are not based on the name of the type, only the types contained in the structs.</div><div class="gmail_quote"><br></div><div class="gmail_quote">TBAA cannot distinguish types solely based on name.</div><div class="gmail_quote"><br></div><div class="gmail_quote">C++ is similar:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">3.10.10</div><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"><span class="m_-3234992859094410469gmail-Apple-converted-space"> </span>If a program attempts to access the stored value of an object through a glvalue of other than one of the<br>following types the behavior is undefined:<span class="m_-3234992859094410469gmail-s1">54<br></span><span class="m_-3234992859094410469gmail-Apple-converted-space"> </span>— the dynamic type of the object,<br>— a cv-qualified version of the dynamic type of the object,<br>— a type similar (as defined in <span class="m_-3234992859094410469gmail-s2">4.4</span> ) to the dynamic type of the object,<br>— a type that is the signed or unsigned type corresponding to the dynamic type of the object,<br>— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type<br>of the object,<br>— an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic<br>data members (including, recursively, an element or non-static data member of a subaggregate<br>or contained union),<br>— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,<br>— a char<span class="m_-3234992859094410469gmail-Apple-converted-space">  </span>or unsigned char<span class="m_-3234992859094410469gmail-Apple-converted-space">  </span>type.</blockquote>











</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">This is not going to end up with a different result in this case.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Do you agree?</div><div class="gmail_quote"><br></div></div></div>
</blockquote></div><br></div></div>