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

[Sean Silva via llvm-commits]

silvas added a subscriber: silvas.
silvas added a comment.

Some initial comments.

You've described a lot of implementation details (and implementation), but haven't described the final intended visitation behavior you are trying to implement (or why). For starters, what's wrong with the old PM CGSCC visitation order that requires doing something fundamentally different in the new PM?

The general idea is clearly to maintain a bottom-up visitation behavior, but since this patch doesn't implement edge addition (which represents devirtualization and so is pretty important) the intended behavior there is unclear. I've put a very specific question about this inline.


================
Comment at: lib/Analysis/CGSCCPassManager.cpp:90
@@ +89,3 @@
+          const Edge *E = N.lookup(*Callee);
+          // FIXME: We should really handle adding new calls. While it will
+          // make downstream usage more complex, there is no fundamental
----------------
What is the plan here? If I'm running `cgscc(foo-cgscc-pass,function(gvn),bar-cgscc-pass)` and gvn devirtualizes a call which increases the size of the SCC, what do we do after finishing the function pass manager? Do we:
1. start back at the beginning with foo-cgscc-pass running on the now-larger SCC?
or
2. continue on to bar-cgscc-pass running on the now-larger SCC?
or
3. something else?


http://reviews.llvm.org/D21464