<div dir="ltr">lgtm<div><br></div><div>Thanks for working through this!  At the end of the day, I think it's better that we don't have a new GEP-like alias construct that optimizations have to worry about, even if we pay for it with less verifiable IR.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 1:37 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> +  return DAG.getNode(XCoreISD::DPRelativeWrapper, dl, MVT::i32, GA);<br>
><br>
> Just to check, there should be no behavioral change here, because getSection<br>
> now looks through aliases for us.<br>
<br>
</div>Correct.<br>
<div class=""><br>
> +// This is only used in aliases that we created and we know they have a<br>
> +// linear structure.<br>
> +static const llvm::GlobalObject *getAliasedGlobal(const llvm::GlobalAlias<br>
> &GA) {<br>
><br>
> Can this be simplified with stripPointerCastsNoFollowAliases() wrapped with<br>
> a loop that follows getAliasee while inserting aliases into Visited?  For<br>
> that matter, does stripPointerCasts infloop on an alias cycle?<br>
<br>
</div>I simplified it and the other cases you suggested. stripPointerCasts<br>
will not infinite loop it will return the GlobalAlias were it first<br>
finds the loop. We still need the set because stripPointerCasts will<br>
not walk past weak aliases (nor should it I think).<br>
<br>
We could add stripPointerCastsAndWeakAliases instead.<br>
<br>
Updated llvm and clang patches attached.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>