[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.

[Daniel Berlin via llvm-commits]

On Fri, Jul 1, 2016 at 1:36 AM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
>>>
>>>> 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.
>

Yes.

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 :)
>

....

So, it's been a few years, and we didn't try this algorithm (we tried
pearce's), but when i tried algorithms to dynamically maintain SCC's and
topo order as part of an andersen's solver, they were slower than just
redoing the ordering/scc finding on each pass :)

So i'd play with them to see how well they work in practice.


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