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

[Chandler Carruth via llvm-commits]

On Thu, Jun 30, 2016 at 9:13 PM Xinliang David Li via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> However when the CG is mutated, what is the definition of 'current' SCC
> and current RefSCC? What is the incremental update algorithm?
>

Note that this patch *does* contain code and comments that I think give
detailed answers here. Not sure it makes sense to hypothesize the algorithm
rather than examining an implementation of the 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160707/854cf637/attachment.html>