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

On Thu, Jun 30, 2016 at 6:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>> 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
>>     * 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.
>>     * How ref-edges are formed, how indirect callsites are handled etc.
>>     * If it is a modification of the classic SCC formation algorithm,
>> describe the change and prove that the algorithm works as expected.
>>
>>
> 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.
>
> In this case, it should not be hard to prove that you can validly form
> both ref and non-ref SCC's at once:
>
> If you were to always follow non-ref edges first, and eagerly collapse
> non-ref SCC's, you can easily prove it will discover the maximal set of
> non-ref sccs (because it's depth first, if there was a cycle that could be
> formed with non-ref edges, it will form it), and each will collapse to a
> node in the ref SCC graph which will then form ref-scc's on top of it by
> following ref-edges.
>
> If you do not follow non-ref edges first, you will get into situations
> where it could have formed a non-ref SCC but formed a ref SCC instead, and
> the non-ref SCC can be non-maximal.
>

Chandler's RefSCC formation considers both ref and non-ref edges, a Ref
SCC's definition is actually maximal SCC with 'mixed' edges. non-ref SCCs
are then formed from a RefSCC.  This part seems ok, I think. However when
the CG is mutated, what is the definition of 'current' SCC and current
RefSCC? What is the incremental update algorithm?

Just some random thoughts: can we assume ref-edges never gets deleted or
added? Can we assume any newly created/exposed call (non-ref) edges always
have corresponding ref edges?  If the above conditions are true, then the
refSCC DAG (DAG with collapsed refSCCs as nodes) can not be mutated. There
is another condition that needs to be met in order for refSCC DAG become
'immutable': a ref edge needs to be introduced for any back edge in CG (if
it is not already a ref edge). This means no new refSCC can appear via
splitting or merging when CG is changed.

If we can guarantee RefSCC DAG is non-mutable,  the incremental update may
be simplified: the SCC update is now guaranteed to be 'intra'-RefSCC (the
current one). Rebuilding SCC within a refSCC could be cheap enough
(assuming refSCCs are not large).

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