<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 5:03 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.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"><div><div class="h5">On Fri, Jul 8, 2016 at 8:31 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Thu, Jun 30, 2016 at 6:36 PM Daniel Berlin via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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 class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>4. The patch introduces a new SCC formation algorithm (double layer with support for CG mutation on the fly), however design document on how this works is missing.  It needs to document </div><div>    * What exactly is expected (in terms of vistation order) when a) an edge is added; b) an edge is deleted; c) when a new node is introduced and connected. </div><div>    * How ref-edges are formed, how indirect callsites are handled etc.</div><div>    * If it is a modification of the classic SCC formation algorithm, describe the change and prove that the algorithm works as expected.</div><div><br></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FWIW: I agree that for algorithms this complex, where we have no other reference for how they are supposed to work, and no way to know what invariants make them correct or not (other than reading code), we should have some design doc.</div></div></div></div></blockquote><div><br></div></span><div>Please see my response to David, there is no disagreement here.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>In this case, it should not be hard to prove that you can validly form both ref and non-ref SCC's at once:<br></div></div></div></div></blockquote><div><br></div></span><div>I'd really like to move this to a separate discussion of LCG. Maybe in response to a separate patch that adds the needed documentation.</div><div><br></div><div>I'm fine if that has to conclude before we review this patch, but this patch is pretty much exclusively using the LCG API to do updates.</div></div></div></blockquote><div><br></div></div></div><div>That's fine.</div><div><br></div><div>I stared at the algorithm it uses, and it is as i expected (and contrary to what i think david said).  It looks like it uses tarjan to revisit the nodes in a found refscc in order to figure out the contained SCC's, which should be provably correct.  It is not strictly necessary to do this, but it's provably O(2N) instead of O(N) worst case, so who cares unless it turns out to be a performance problem in practice, who cares.  The only case i could see it mattering is if you have large ref sccs where the internal sccs are all single node or something.</div></div></div></div></blockquote><div><br></div><div>Wait -- what you described here is what I said too, but the algorithm is different from your proposal (which is more efficient) :)</div><div><br></div><div>For reference,  I am not concerned about this ref-scc/scc construction part, but the part that deals with update.  I believe Chandler himself have the same concerns according to what he wrote in the summary (bullet 2, 3 etc) for the patch.</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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div>It still should be overall documented (as we've all agreed), so that me and you are hopefully not the only two who understand it :)</div></div></div></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>The update algorithms could be sped up in time bounds, but again, without data saying it's a perf problem, i'd pass on it since it looks like they have verification functions to make sure they work.</div></div></div></div></blockquote><div><br></div><div>I think it is mostly the update algorithm that needs to be documented/examined, which is also strongly tied to the rationale why refSCC is needed. If it is the core part of the new CGSCC PM, we need to make sure the path taken is fully correct.</div><div><br></div><div>David</div><div> </div></div><br></div></div>