[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