<div dir="ltr"><div class="gmail_extra">Just FYI,</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 1, 2013 at 11:18 AM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank" class="cremed">aschwaighofer@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":8lh" style="overflow:hidden">- Using GetElementPtr during the analysis.<br>
<br>
  Part of the current analysis depends on two geps with matching pointer types. I don’t think this is the right approach. Two differently typed GetElementPtr’s can compute the same access function. The GetElementPtr is only a way to describe address computation. GetElementPtrs don’t impose interesting constraints (see my next point) that would not be embodied by the ScalarEvolution of the pointer. But the ScalarEvolution is in a canonical form and therefore we would not need to dependent on matching gep pointer types.<br>

  I believe the analysis should directly work from and directly interpret the ScalarEvolution function describing the access function.</div></blockquote></div><br>This has come up before. I made similar comments a long time ago about the dependence analysis pass. I really think that it is using GEPs as though they were SCEV descriptions of a pointer, and would be substantially better to implement (as you describe) in terms of SCEVs directly.</div>
</div>