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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112696