<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev <span dir="ltr" class="gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg">2016-12-23 22:17 GMT+01:00 David Majnemer <span dir="ltr" class="gmail_msg"><<a href="mailto:david.majnemer@gmail.com" class="gmail_msg" target="_blank">david.majnemer@gmail.com</a>></span>:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-7251184104372978012m_-8435937672374749700h5 gmail_msg">On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev <span dir="ltr" class="gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-7251184104372978012m_-8435937672374749700m_5421489064941797502gmail- gmail_msg">On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski<br class="gmail_msg">
<<a href="mailto:piotr.padlewski@gmail.com" class="gmail_msg" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On Dec 23, 2016 19:47, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" class="gmail_msg" target="_blank">dberlin@dberlin.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Define soon?<br class="gmail_msg">
> My guess is 1 year or less.<br class="gmail_msg">
> (I've already seen patches to start converting most remaining memdep uses,<br class="gmail_msg">
> like memcpy opt, licm, etc)<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> That's good. Anyway I already have a patch that is doing invariant group<br class="gmail_msg">
> dependence across BBs, so I guess it make sense to push it upstream to push<br class="gmail_msg">
> the bar higher.<br class="gmail_msg">
> But I think we are getting a little bit of topic - should gep 0 be<br class="gmail_msg">
> canonicalized to bitcast?<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</span>Are memdep/memssa the only possible passes that could benefit from<br class="gmail_msg">
such a canonicalization or you can think of other cases when this can<br class="gmail_msg">
be useful?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg">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" class="gmail_msg" target="_blank">https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024</a></div><span class="gmail_msg"><div class="gmail_msg"> </div></span></div></div></div></blockquote></span><div class="gmail_msg">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 class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">+1</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This canonicalization seems like it's unlikely to help other passes, and definitely makes handling more complicated elsewhere.</div></div></div></div></blockquote><div><br></div><div>-1</div><div>;]</div><div><br></div><div>I think it is very useful to be able to canonicalize on GEPs rather than bitcasts. I would teach things to understand GEPs with zero indices, it's pretty easy (we have tools to automate it).</div><div><br></div><div>One reason why is that most things that want to reason about all-zero GEPs probably want to reason about all-constant GEPs as well. Certainly, I would expect MemDep and things like invariant.group to survive all-constant GEPs too.</div><div><br></div><div>Note that even this ambiguity of which direction to canonicalize will go away with typeless pointers as we won't have to choose one or the other.</div></div></div>