<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 8:47 AM 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"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, May 1, 2017 at 3:48 AM, Chandler Carruth 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"><div dir="ltr">Today, the IR requires that if you have multiple edges from A to B (typically with a switch) any phi nodes in B must have an equal number of entries for A, but that all of them must have the same value.</div></blockquote><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><br></div><div>This seems rather annoying....</div><div>1) It creates multiple uses of values in A for no apparently good reason</div><div>2) It makes updating PHI nodes using sets of predecessors incredibly hard</div><div>3) There is no correspondence between the edges and the PHI node entries other than number, making most of the code that does handle this very ad-hoc "count off N repetitions of the same thing" style code, which is brittle and hard to test effectively.</div></div></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>Having written this code a few times, i'd agree.</div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><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>4) I suspect bugs are quite common given that PHINode::removeIncomingValue accepts a basic block but only removes the first incoming value, leaving the others in place.</div></div></blockquote><div><br></div><div> </div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><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><br></div><div>I can't see any serious use case for this symmetry either. These aren't uses (and can't be), and there doesn't seem to be any lost functionality if we only have a single entry.<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></div></blockquote></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><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><br></div><div>It also seems likely to open up more efficient in-memory representations if it is possible at some point to build maps of these things.</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><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></blockquote><div><br></div><br class="m_-902498215182779162gmail-Apple-interchange-newline">So would this lead to a case where PHI->getNumOperands() != std::distance(pred_begin(phiblock), pred_end(phiblock))<div><br></div><div>If so, that would seem problematic to handle as well.</div><div>:(</div></div></div></div></div></blockquote><div><br></div><div>How problematic?</div><div><br></div><div>The places I've looked at that cared had to build a data structure anyways (the verifier builds two vectors and sorts them). Having them build sets wouldn't seem problematic.</div><div><br></div><div>But I've only looked at a couple of places, which is somewhat the point of this email -- I'd like to know if we're doing this for good reasons, and ideally understand those reasons.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></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> It appears entirely possible to change the verifier to check that we don't have duplicates, and to read bitcode with duplicates and merge them so that there is no backwards compatibility issue.</div><span class="m_-902498215182779162gmail-HOEnZb"><font color="#888888"><div><br></div><div>-Chandler</div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>