<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</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"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail-h5"><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" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_extra gmail-m_9120949883116771958gmail_msg"><div class="gmail_quote gmail-m_9120949883116771958gmail_msg">On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev <span dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail-m_9120949883116771958gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail-m_9120949883116771958gmail_msg"><blockquote class="gmail_quote gmail-m_9120949883116771958gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_extra gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_quote gmail-m_9120949883116771958gmail_msg"><span class="gmail-m_9120949883116771958gmail_msg">2016-12-23 22:17 GMT+01:00 David Majnemer <span dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><<a href="mailto:david.majnemer@gmail.com" class="gmail-m_9120949883116771958gmail_msg" target="_blank">david.majnemer@gmail.com</a>></span>:<br class="gmail-m_9120949883116771958gmail_msg"><blockquote class="gmail_quote gmail-m_9120949883116771958gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_extra gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_quote gmail-m_9120949883116771958gmail_msg"><div class="gmail-m_9120949883116771958gmail_msg"><div class="gmail-m_9120949883116771958m_-7251184104372978012m_-8435937672374749700h5 gmail-m_9120949883116771958gmail_msg">On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev <span dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail-m_9120949883116771958gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail-m_9120949883116771958gmail_msg"><blockquote class="gmail_quote gmail-m_9120949883116771958gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_9120949883116771958m_-7251184104372978012m_-8435937672374749700m_5421489064941797502gmail- gmail-m_9120949883116771958gmail_msg">On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski<br class="gmail-m_9120949883116771958gmail_msg">
<<a href="mailto:piotr.padlewski@gmail.com" class="gmail-m_9120949883116771958gmail_msg" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
> On Dec 23, 2016 19:47, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" class="gmail-m_9120949883116771958gmail_msg" target="_blank">dberlin@dberlin.org</a>> wrote:<br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
> Define soon?<br class="gmail-m_9120949883116771958gmail_msg">
> My guess is 1 year or less.<br class="gmail-m_9120949883116771958gmail_msg">
> (I've already seen patches to start converting most remaining memdep uses,<br class="gmail-m_9120949883116771958gmail_msg">
> like memcpy opt, licm, etc)<br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
> That's good. Anyway I already have a patch that is doing invariant group<br class="gmail-m_9120949883116771958gmail_msg">
> dependence across BBs, so I guess it make sense to push it upstream to push<br class="gmail-m_9120949883116771958gmail_msg">
> the bar higher.<br class="gmail-m_9120949883116771958gmail_msg">
> But I think we are getting a little bit of topic - should gep 0 be<br class="gmail-m_9120949883116771958gmail_msg">
> canonicalized to bitcast?<br class="gmail-m_9120949883116771958gmail_msg">
><br class="gmail-m_9120949883116771958gmail_msg">
<br class="gmail-m_9120949883116771958gmail_msg">
</span>Are memdep/memssa the only possible passes that could benefit from<br class="gmail-m_9120949883116771958gmail_msg">
such a canonicalization or you can think of other cases when this can<br class="gmail-m_9120949883116771958gmail_msg">
be useful?<br class="gmail-m_9120949883116771958gmail_msg"></blockquote><div class="gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"></div></div></div><div class="gmail-m_9120949883116771958gmail_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-m_9120949883116771958gmail_msg" target="_blank">https://github.com/<wbr>llvm-mirror/llvm/blob/master/<wbr>lib/Transforms/InstCombine/<wbr>InstCombineCasts.cpp#L2024</a></div><span class="gmail-m_9120949883116771958gmail_msg"><div class="gmail-m_9120949883116771958gmail_msg"> </div></span></div></div></div></blockquote></span><div class="gmail-m_9120949883116771958gmail_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-m_9120949883116771958gmail_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-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_9120949883116771958gmail_msg"><div class="gmail_extra gmail-m_9120949883116771958gmail_msg"><div class="gmail_quote gmail-m_9120949883116771958gmail_msg"><div class="gmail-m_9120949883116771958gmail_msg">+1</div><div class="gmail-m_9120949883116771958gmail_msg"><br class="gmail-m_9120949883116771958gmail_msg"></div><div class="gmail-m_9120949883116771958gmail_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></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. </div></div></div></blockquote><div><br></div><div>Based on what?  <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I would teach things to understand GEPs with zero indices, it's pretty easy (we have tools to automate it).</div></div></div></blockquote><div><br></div><div>So your position is that we should teach literally everything to understand something new, instead of canonicalize in the direction literally everything understands already?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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.</div></div></div></blockquote><div>This is about the equivalence of gep 0,0 to bitcast. They aren't equivalent to other types of geps, so reasoning about them seems very different and orthogonal to me.</div><div>You are saying "well things *should* understand all constant GEP anyway". That may or may not be true, but it's, IMHO, pretty orthogonal to how we choose to canonicalize a given operation.<br></div><div>You are also suggesting representing an operation in something significantly more complicated than it's direct form.</div><div><div><br class="gmail-Apple-interchange-newline">Also, can you provide some data?</div><div>You say "most" and "probably" with no explicit examples.</div></div><div>Can you pull out an explicit example of how it would help existing passes, both optimization, and analysis, vs canonicalizing to bitcast?<br></div><div><br>Because i'll be honest, i'm not seeing it.  It seems like a more complicated form, for no good reason.</div><div><br></div><div>It would be like canonicalizing  add's to xor's.  You can do it, and "most things that reason about adds probably want to reason about xors".</div><div>However, i think we'd all agree that add is a much simpler and direct form, and very directly represents the operation.</div><div>We should, IMHO, do the same here.  If something wants to see it as a GEP, it can see it as a GEP.</div><div><br></div><div>Arguing that "well, passes should handle GEP anyway" is literally the same as arguing "well, passes should understand xor anyway".</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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>
</blockquote></div><br></div></div>