[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 llvm-commits at lists.llvm.org
Tue Jun 28 18:33:01 PDT 2016


silvas added inline comments.

================
Comment at: lib/Analysis/CGSCCPassManager.cpp:90
@@ +89,3 @@
+    for (Instruction &I : BB)
+      if (auto CS = CallSite(&I))
+        if (Function *Callee = CS.getCalledFunction())
----------------
chandlerc wrote:
> (in case reading this against the current patch, this originally was attached to the FIXME regarding handling adding new calls)
> 
> As i somewhat alluded to above, what you describe should be handled by a ref edge turning into a call edge, and the update mechanism should be able to handle that well.
> 
> I've added a test case that exercises this with GVN and function-attrs. There is currently a case missed in the new pass manager because we don't have the up-to-four iteration whenever an indirect call turns into a direct call heuristic that the old pass manager has. I'm happy to add that, but I'd like to add it in a follow-up patch. I've marked where in the test case this is missed, and I've demonstrated that in theory this update mechanism is sufficient to handle it by explicitly running function-attrs again and it correctly catches the refinement.
> 
> The direct answer to your question is #2: it continues running on the now-larger SCC, detects that we switch from one SCC to another at some point, and re-runs on that SCC to make sure that the refined graph is observed.
> As i somewhat alluded to above, what you describe should be handled by a ref edge turning into a call edge, and the update mechanism should be able to handle that well.

Please add test cases exhibiting this.

> The direct answer to your question is #2: it continues running on the now-larger SCC, detects that we switch from one SCC to another at some point, and re-runs on that SCC to make sure that the refined graph is observed.

Okay, please add a test case for that. Also add a test case demonstrating that we don't go quadratic on a graph like http://reviews.llvm.org/F2110388

```
digraph "foo bar" {
  rankdir=LR
  A -> B; B -> A [style=dashed,label="ref"];
  B -> C; C -> B [style=dashed,label="ref"];
  C -> D; D -> C [style=dashed,label="ref"];
  D -> E; E -> D [style=dashed,label="ref"];
}
```

where function passes manage to devirtualize all the ref edges.


http://reviews.llvm.org/D21464





More information about the llvm-commits mailing list