<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 10:24 AM, Sanjoy Das 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ashutosh,<br>
<span class=""><br>
On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I’m not sure how transforming GEP offset to i8 type will help alias analysis<br>
> & SROA for the mentioned test case.<br>
<br>
</span>It should neither help nor hinder AA or SROA -- the two GEPs (the<br>
complex one and the simple one) are equivalent.  Since memory isn't<br>
typed in LLVM, having the GEP in terms of %struct.ABC does not provide<br>
any extra information.<br></blockquote><div><br></div><div>FWIW: Having memory be untyped strongly hinders field sensitive analysis :)<br></div><div>It's okay for non, obviously.</div><div><br></div><div>I also get the desire to avoid bitcasts.</div><div>But field-sensitive analysis of any sort requires knowing that memory has structures and arrays, and we've said "no it doesn't :)</div><div><br></div><div>So either you spend all your time trying to recover that based on the indexing operations you see(at precision loss), provide metadata and base your analysis on the metadata (which must stay semantically correct, since you are effectively ignoring the addressing operation), or give up.</div><div>(Analyses like DSA attempt to recover it).<br></div><div><br></div><div>We already miss pretty basic field aliasing cases in C++ due to the above :(<br></div><br></div></div></div>