<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski 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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2016-12-23 22:17 GMT+01:00 David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span>:<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"><div><div class="m_-8435937672374749700h5">On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano 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"><span class="m_-8435937672374749700m_5421489064941797502gmail-">On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski<br>
<<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br>
><br>
><br>
> On Dec 23, 2016 19:47, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" target="_blank">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></div></div><div>We already canonicalize.  We canonicalize in the other direction: <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024" target="_blank">https://github.com/<wbr>llvm-mirror/llvm/blob/master/l<wbr>ib/Transforms/InstCombine/Inst<wbr>CombineCasts.cpp#L2024</a></div><span><div> </div></span></div></div></div></blockquote></span><div>Intresting. So what is the right solution here? I can easily add handling of gep 0 to GVN, or maybe the code that you mentioned should be in SROA. </div><div>If SROA is the only user of this transformation and I there are quiet a few passes that it hurts, then I would propose moving this logic to SROA and always canonicalize gep 0 to bitcast.</div></div></div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>This canonicalization seems like it's unlikely to help other passes, and definitely makes handling more complicated elsewhere.</div><div> <br></div></div></div></div>