<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">That said, I'm not sure why you need to find the entry point of the program.<br></span><span style="font-size:12.8px">SCCs (collapsed) create a DAG so you can first propagate the attribute<br></span><span style="font-size:12.8px">within the SCC (until convergence) and then propagate across SCCs (see<br></span><span style="font-size:12.8px">the strong component section of<br></span><a href="http://www.imm.dtu.dk/~hrni/PPA/slides6.pdf" rel="noreferrer" target="_blank" style="font-size:12.8px">http://www.imm.dtu.dk/~hrni/<wbr>PPA/slides6.pdf</a><span style="font-size:12.8px"> ). Unless I misunderstood<br></span><span style="font-size:12.8px">your problem (which I might have :), </span></blockquote><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">OK cool, the slideshow clarified what SCCs do. </span>So it looks like scc_iterator will navigate the reduced graph in topological order, which means all I have to worry about are describing the graphtraits, and the scc_iterator does the rest?</div><div><span style="font-size:12.8px"><br></span></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">you don't need to start from the </span><span style="font-size:12.8px">entry point, as long as you have a topological order.</span></blockquote><div><br></div><div>That makes sense. I was going off the implementation of the callgraph (which starts at the callgraph's entry point), but I was misinterpreting the significance of that. It looks like my problem is just a bug in my GraphTraits implementation then, because I'm only finding 2 SCCs (each with one node) in my test example which should be finding 10 nodes. </div></div><div><br></div><div>Thanks for the help Davide!</div><div>- Charles</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 3:39 AM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Aug 9, 2017 at 3:04 PM, Charles Saternos via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I just realized that I've been misunderstanding this (I think). If I'm<br>
> understanding it now, the entry node for the graph should actually be the<br>
> graph's root (not a bottom node), and that the scc_iterator works its way<br>
> down. So for the ModuleSummary, I should find the main function and return<br>
> that (or whatever function is the entry point for the entire program).<br>
><br>
<br>
</span>You can look at how the traits are used. Several passes in tree use<br>
them, so you can get an idea (look for CGSCC, for example, the<br>
inliner). Also, SCCs are discovered in post-order. If you want a<br>
different visitation order you should built that yourself on top of<br>
the existing one (see for example the code in FunctionAttrs.cpp which<br>
discovers the SCC in RPO).<br>
<br>
That said, I'm not sure why you need to find the entry point of the program.<br>
SCCs (collapsed) create a DAG so you can first propagate the attribute<br>
within the SCC (until convergence) and then propagate across SCCs (see<br>
the strong component section of<br>
<a href="http://www.imm.dtu.dk/~hrni/PPA/slides6.pdf" rel="noreferrer" target="_blank">http://www.imm.dtu.dk/~hrni/<wbr>PPA/slides6.pdf</a> ). Unless I misunderstood<br>
your problem (which I might have :), you don't need to start from the<br>
entry point, as long as you have a topological order.<br>
<br>
--<br>
Davide<br>
</blockquote></div><br></div>