[PATCH] D112696: CycleInfo: Introduce cycles as a generalization of loops

[Sameer Sahasrabuddhe via Phabricator via llvm-commits]

sameerds added inline comments.


================
Comment at: llvm/docs/CycleTerminology.rst:35
+   said to be the *parent* of these cycles, and each of these cycles
+   is a *child* of C.
+
----------------
sameerds wrote:
> foad wrote:
> > Hi @sameerds, I have a question about this: why does #5 talk about "a cycle C **with header H**" (which depends on a particular DFS), instead of "a cycle C with entries E" (which would not)? It seems like this would make the cycle nesting structure depend on the choice of DFS. Is that intentional? It is unavoidable?
> This is more about maximizing how much hierarchy we can uncover in a given irreducible graph. The current technique picks one entry of a cycle C as the header H in a mostly arbitrary way, and then discovers more cycles in the subgraph `C-H`. We could instead choose to explore the subgraph `C-E`, but that just means that we are likely to discover fewer subcyles. The cost of choosing `C-H` is that we make everything implementation/DFS dependent, but I think it's worth it. I don't think this dependence is unavoidable; it just makes the hierarchy more useful. 
On second thought, excluding the header is indeed unavoidable. Without that, we cannot make statements like property 4: "In any cycle hierarchy, the header H of the smallest cycle C containing a closed path P itself lies on P." If we used `C-E`, then we break any closed paths that are included in `C` but do not pass through `H`. Such paths will not pass through the header of any cycle.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112696/new/

https://reviews.llvm.org/D112696