<div dir="ltr">GVN definitely does not detect that GEP 0,0 and bitcast are equivalent, so it will miss later equivalences based on them.<div>We could teach it, of course.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski<br>
<<a href="mailto:piotr.padlewski@gmail.com">piotr.padlewski@gmail.com</a>> wrote:<br>
><br>
><br>
> On Dec 23, 2016 19:47, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
><br>
> Define soon?<br>
> My guess is 1 year or less.<br>
> (I've already seen patches to start converting most remaining memdep uses,<br>
> like memcpy opt, licm, etc)<br>
><br>
><br>
> That's good. Anyway I already have a patch that is doing invariant group<br>
> dependence across BBs, so I guess it make sense to push it upstream to push<br>
> the bar higher.<br>
> But I think we are getting a little bit of topic - should gep 0 be<br>
> canonicalized to bitcast?<br>
><br>
<br>
</span>Are memdep/memssa the only possible passes that could benefit from<br>
such a canonicalization or you can think of other cases when this can<br>
be useful?<br>
</blockquote></div><br></div>