[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
llvm-commits at lists.llvm.org
Thu Jul 7 15:32:02 PDT 2016
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).
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits