<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-12-24 9:39 GMT+01:00 Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span>:<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><div class="gmail-h5"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <<a href="mailto:dberlin@dberlin.org" class="gmail-m_-8377109911651072869gmail_msg" target="_blank">dberlin@dberlin.org</a>> wrote:<br class="gmail-m_-8377109911651072869gmail_msg"></div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <span dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><<a href="mailto:chandlerc@google.com" class="gmail-m_-8377109911651072869gmail_msg" target="_blank">chandlerc@google.com</a>></span> wrote:<br class="gmail-m_-8377109911651072869gmail_msg"><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-h5 gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail-m_-8377109911651072869gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail-m_-8377109911651072869gmail_msg"></div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev <span dir="ltr" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><blockquote class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><span class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">2016-12-23 22:17 GMT+01:00 David Majnemer <span dir="ltr" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><<a href="mailto:david.majnemer@gmail.com" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" target="_blank">david.majnemer@gmail.com</a>></span>:<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><blockquote class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958m_-7251184104372978012m_-8435937672374749700h5 gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev <span dir="ltr" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><<a href="mailto:llvm-dev@lists.llvm.org" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><blockquote class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958m_-7251184104372978012m_-8435937672374749700m_5421489064941797502gmail- gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
<<a href="mailto:piotr.padlewski@gmail.com" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> On Dec 23, 2016 19:47, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg" target="_blank">dberlin@dberlin.org</a>> wrote:<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> Define soon?<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> My guess is 1 year or less.<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> (I've already seen patches to start converting most remaining memdep uses,<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> like memcpy opt, licm, etc)<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> That's good. Anyway I already have a patch that is doing invariant group<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> dependence across BBs, so I guess it make sense to push it upstream to push<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> the bar higher.<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> But I think we are getting a little bit of topic - should gep 0 be<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
> canonicalized to bitcast?<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
</span>Are memdep/memssa the only possible passes that could benefit from<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
such a canonicalization or you can think of other cases when this can<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">
be useful?<br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"></blockquote><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"></div></div></div><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"> </div></span></div></div></div></blockquote></span><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg">+1</div><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-m_9120949883116771958gmail_msg gmail-m_-8377109911651072869gmail_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 class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div><div class="gmail-m_-8377109911651072869gmail_msg">-1</div><div class="gmail-m_-8377109911651072869gmail_msg">;]</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">I think it is very useful to be able to canonicalize on GEPs rather than bitcasts. </div></div></div></blockquote><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">Based on what?</div></div></div></div></blockquote><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">TBH, no hard data at all. Just my experience poking at passes that cared about this and the advice I received from others when hacking on them. Sorry if anything I wrote came off as some kind of firm, or unwavering position, it was more that I'm not sure the proposed change is good. It might be, but I'm not sure yet. See below for more details though.</div></div></div></div><span class="gmail-"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">  <br class="gmail-m_-8377109911651072869gmail_msg"> </div></div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">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 class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">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></div></blockquote><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div></span><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">Not at all.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">All-zero-GEPs aren't new for better or worse. We've been canonicalizing toward them since before Chris refactored all of this code in 2007, so this is a very long-standing pattern even if it is a bad one. And several parts of LLVM of course handle them. They have to given that we're canonicalizing that direction.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">I learned of this years ago when Duncan Sands taught me about it to explain why my SROA rewrite hit so many all-zero GEPs. Since then, it hasn't seemed to me personally like a significant issue that we canonicalize towards all-zero GEPs. And I've not heard many folks hit issues with it since then. So my advice is typically "yep, you need to handle all-zero GEPs". That's essentially the default for when a pass doesn't handle canonical form.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">It isn't an endorsement though, and it doesn't mean we can't or shouldn't change the canonical form! If we have new evidence that makes a change warranted, we absolutely should. Some kinds of evidence I can remember in the past motivating a change:</div><div class="gmail-m_-8377109911651072869gmail_msg">1) It's really hard and/or awkward to teach things about the canonical form.</div><div class="gmail-m_-8377109911651072869gmail_msg">2) The canonical form doesn't express as much information or is in any other way a less useful/expressive representation.</div><div class="gmail-m_-8377109911651072869gmail_msg">3) Empirical evidence shows that a different canonical form despite being perfectly equivalent on the prior two points, is less convenient.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">The statement from Piotr that it is easy to teach GVN about this seems to indicate we're not talking about the first two issues, but if we are, that's a whole new discussion (and an interesting one).</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">It seems possible that #3 is true (I suspect you think #3 is true from your email at least). While we should in general fix these kinds of issues when we find them, it does seem somewhat less urgent. And since there are conflicting experiences, we probably want at least a comprehensive survey before we make a change.</div></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">In this particular case I suspect that we *used* to have issues related to #2 -- SROA before my rewrite relied on GEPs to understand type structures being decomposed. While I *think* all of the semantic issues here are gone, a number of people in the last couple of years have still insisted that bitcasting pointers blocks optimizations so we should at least investigate this prior to making a change.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">But this led me to the last paragraph in my email -- if all of this goes away with typeless pointers, it's not clear that it's worth pursuing a change for #3. Not saying we definitely shouldn't, just that we should weigh that against removing types from pointers entirely so that these issues don't come at all, regardless of how we spell the instruction.</div></div></div></div><span class="gmail-"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"> </div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">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></div></div><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">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 class="gmail-m_-8377109911651072869gmail_msg">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 class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">You are also suggesting representing an operation in something significantly more complicated than it's direct form.</div></div></div></div></blockquote><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div></span><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">Sorry it seemed orthogonal. All I meant was that handling all zero GEPs might be unusually low cost because of handling all constant GEPs. That only really speaks to #3 above, and it really only lessens the cost. As you say, it can't eliminate it as a GEP is different from a bitcast and so we may end up handling both.</div></div></div></div><span class="gmail-"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><blockquote class="gmail_quote gmail-m_-8377109911651072869gmail_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_-8377109911651072869gmail_msg"><div class="gmail_extra gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869m_-5534915327448231131m_-7583822776996345388m_7608674570905503393gmail-Apple-interchange-newline gmail-m_-8377109911651072869gmail_msg">Also, can you provide some data?</div><div class="gmail-m_-8377109911651072869gmail_msg">You say "most" and "probably" with no explicit examples.</div></div><div class="gmail-m_-8377109911651072869gmail_msg">Can you pull out an explicit example of how it would help existing passes, both optimization, and analysis, vs canonicalizing to bitcast?</div></div></div></div></blockquote><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div></div></div></div></span><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div dir="ltr" class="gmail-m_-8377109911651072869gmail_msg"><div class="gmail_quote gmail-m_-8377109911651072869gmail_msg"><div class="gmail-m_-8377109911651072869gmail_msg">Well, my intent here was not to say it would *help* existing passes but only that several existing passes already handled all constant GEPs and the all zero case largely fell out as a consequence.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">The example I'm most familiar with is SROA of course. In all but one place it uses code to handle all constant GEPs and doesn't need to special case all zero GEPs. BasicAA appears to be similar. The vectorizers also seem to have existing code handling constant GEPs that would handle zero GEPs for free.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">As for examples of where it would *help* in a fundamental way? No, I think all of those are gone. It used to help SROA before the rewrite. It also helped DependenceAnalysis before it was rewritten. The first was crippled by relying on this but remaining conservatively correct. The second was actually buggy because it relied on this without remaining conservatively correct. LLVM has been moving away from this being a useful thing to *fundamentally* rely on.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">Examples of where it would help in a trivial way? Any pass that handles all-constant-GEPs, but not bitcasts. We could easily teach such a pass to handle bitcasts though. We could also teach the passes that handle bitcasts to handle all-zero-GEPs. In fact, we've automated this for most passes with stripPointerCasts and friends.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg"><br></div><div class="gmail-m_-8377109911651072869gmail_msg">I don't see a fundamental advantage of one over the other, so we're left with essentially an engineering tradeoff. If we weren't planning to remove pointer types entirely, this would still be an important engineering tradeoff, but I'm not sure which way it would go. Given that we're planning to remove pointer types entirely, I'd rather focus on that change rather than changing canonicalization strategies, and patch passes to cope with today's canonical form until we finish. But that is a fairly mild "rather". New information could quite easily change my mind. And it is just my two cents of course.</div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg"><br class="gmail-m_-8377109911651072869gmail_msg"></div><div class="gmail-m_-8377109911651072869gmail_msg">Anyways, again, sorry if my previous email came off as a mandate, I just meant to indicate that the issue was not clear cut to me, not that it was some kind of definite thing one way or the other.</div></div></div></div></div></blockquote><div><br></div><div>Ok I get your point. </div><div>- If every gep 0, 0 would be bitcast, then we would still need code to handle all constant geps that would handle this case, but we also need code to handle bitcasts that will be gone some time</div><div>- if we stay with gep 0, 0 then places like GVN that doesn't handle it right now should probably handle all constant geps anyway, so it doesn't matter in which form it is.</div><div><br></div><div>I didn't investigate how hard it would be to handle geps 0 or constant geps in GVN, but at least for handling of invariant groups it required 2 lines of code. I did look a little bit into SROA and I don't see a clear solution to handle bitcasts for SROA yet, so it also might be argument against bitcasts (but I also not familiar with SROA and didn't spend enough time on it).</div><div>When do we expect to deploy typeless pointers?</div><div><br></div><div>@dannyb are you fine with me writing this small hotfix for invariant group? </div><div><br></div><div>Piotr </div></div></div></div>