[PATCH] D21464: [PM] WIP: Introduce basic update capabilities to the new PM's CGSCC pass manager, including both plumbing and logic to handle function pass updates.

[Xinliang David Li via llvm-commits]

>
>>
>>> Perhaps i am missing something, however.  I will stare at the patch.
>>>
>>
>>
>> Looks like what complicates the matter is that the SCC formation is done
>> on the fly while the graph is traversed/iterated (lazily formed).
>>
>
>
> This is standard, tarjan's algorithm works just fine in that case.
>

yes -- my point is that with your algorithm, the non-ref sccs will need to
be formed eagerly first and then forming refSCCs can be done in a lazy
fashion.



>
>
>> In order to ensure the visit order, the RefSCCs are formed first.
>>
>
> In the algorithm above, the ref-scc's should also be output in topo-order,
> because we only visit successor ref-scc's after we've formed a given
> ref-scc.
>
> You just have to track the relative orders.
>
> Note that you can even do it multi-core in quasi-linear time and get
> serious speedups.
> http://conf.researchr.org/home/PPoPP-2016
>
> (search for "Multi-core on-the-fly SCC decomposition". the conference is
> open access, so you will have access to the paper, but if i direct link it,
> it don't work)
>
>
>
>
>> Thanks for the reference! I have not read it in details, but just
>> browsing through the algorithm, if it is employed to do dynamic cycle
>> update and node reordering -- there does not seem to be need for Ref edges
>> and Ref SCC at all.  Looking at the example in Figure 2. Reverse top-order
>> of the callgraph is first formed. The SCC pass manager processes 'j', and
>> then node 'v'. After processing 'v', a new call edge is discovered to node
>> 'w', incremental update is applied, and 'v' 's analysis result is
>> invalidated and will be processed later. The pass manager will then process
>> 'h', 'i', 'f'
>>
>>
> Be careful, all of these algorithms are N^2.
>
>

For sparse graph (which CG usually is), the soft threshold search algorithm
to maintain SCC has complexity of O(m^3/2) where m is the number of new
arcs added -- so it does not look too bad :)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160701/833d433d/attachment.html>