mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
ef741a9d22
entire SCC before iterating on newly-introduced call edges resulting from any inlined function bodies. This more closely matches the behavior of the old PM's inliner. While it wasn't really clear to me initially, this behavior is actually essential to the inliner behaving reasonably in its current design. Because the inliner is fundamentally a bottom-up inliner and all of its cost modeling is designed around that it often runs into trouble within an SCC where we don't have any meaningful bottom-up ordering to use. In addition to potentially cyclic, infinite inlining that we block with the inline history mechanism, it can also take seemingly simple call graph patterns within an SCC and turn them into *insanely* large functions by accidentally working top-down across the SCC without any of the threshold limitations that traditional top-down inliners use. Consider this diabolical monster.cpp file that Richard Smith came up with to help demonstrate this issue: ``` template <int N> extern const char *str; void g(const char *); template <bool K, int N> void f(bool *B, bool *E) { if (K) g(str<N>); if (B == E) return; if (*B) f<true, N + 1>(B + 1, E); else f<false, N + 1>(B + 1, E); } template <> void f<false, MAX>(bool *B, bool *E) { return f<false, 0>(B, E); } template <> void f<true, MAX>(bool *B, bool *E) { return f<true, 0>(B, E); } extern bool *arr, *end; void test() { f<false, 0>(arr, end); } ``` When compiled with '-DMAX=N' for various values of N, this will create an SCC with a reasonably large number of functions. Previously, the inliner would try to exhaust the inlining candidates in a single function before moving on. This, unfortunately, turns it into a top-down inliner within the SCC. Because our thresholds were never built for that, we will incrementally decide that it is always worth inlining and proceed to flatten the entire SCC into that one function. What's worse, we'll then proceed to the next function, and do the exact same thing except we'll skip the first function, and so on. And at each step, we'll also make some of the constant factors larger, which is awesome. The fix in this patch is the obvious one which makes the new PM's inliner use the same technique used by the old PM: consider all the call edges across the entire SCC before beginning to process call edges introduced by inlining. The result of this is essentially to distribute the inlining across the SCC so that every function incrementally grows toward the inline thresholds rather than allowing the inliner to grow one of the functions vastly beyond the threshold. The code for this is a bit awkward, but it works out OK. We could consider in the future doing something more powerful here such as prioritized order (via lowest cost and/or profile info) and/or a code-growth budget per SCC. However, both of those would require really substantial work both to design the system in a way that wouldn't break really useful abstraction decomposition properties of the current inliner and to be tuned across a reasonably diverse set of code and workloads. It also seems really risky in many ways. I have only found a single real-world file that triggers the bad behavior here and it is generated code that has a pretty pathological pattern. I'm not worried about the inliner not doing an *awesome* job here as long as it does *ok*. On the other hand, the cases that will be tricky to get right in a prioritized scheme with a budget will be more common and idiomatic for at least some frontends (C++ and Rust at least). So while these approaches are still really interesting, I'm not in a huge rush to go after them. Staying even closer to the existing PM's behavior, especially when this easy to do, seems like the right short to medium term approach. I don't really have a test case that makes sense yet... I'll try to find a variant of the IR produced by the monster template metaprogram that is both small enough to be sane and large enough to clearly show when we get this wrong in the future. But I'm not confident this exists. And the behavior change here *should* be unobservable without snooping on debug logging. So there isn't really much to test. The test case updates come from two incidental changes: 1) We now visit functions in an SCC in the opposite order. I don't think there really is a "right" order here, so I just update the test cases. 2) We no longer compute some analyses when an SCC has no call instructions that we consider for inlining. llvm-svn: 297374
105 lines
2.9 KiB
LLVM
105 lines
2.9 KiB
LLVM
; This test tries to ensure that the inliner successfully invalidates function
|
|
; analyses after inlining into the function body.
|
|
;
|
|
; The strategy for these tests is to compute domtree over all the functions,
|
|
; then run the inliner, and then verify the domtree. Then we can arrange the
|
|
; inline to disturb the domtree (easy) and detect any stale cached entries in
|
|
; the verifier. We do the initial computation both *inside* the CGSCC walk and
|
|
; in a pre-step to make sure both work.
|
|
;
|
|
; RUN: opt < %s -passes='function(require<domtree>),cgscc(inline,function(verify<domtree>))' -S | FileCheck %s
|
|
; RUN: opt < %s -passes='cgscc(function(require<domtree>),inline,function(verify<domtree>))' -S | FileCheck %s
|
|
|
|
; An external function used to control branches.
|
|
declare i1 @flag()
|
|
; CHECK-LABEL: declare i1 @flag()
|
|
|
|
; The utility function with interesting control flow that gets inlined below to
|
|
; perturb the dominator tree.
|
|
define internal void @callee() {
|
|
; CHECK-LABEL: @callee
|
|
entry:
|
|
%ptr = alloca i8
|
|
%flag = call i1 @flag()
|
|
br i1 %flag, label %then, label %else
|
|
|
|
then:
|
|
store volatile i8 42, i8* %ptr
|
|
br label %return
|
|
|
|
else:
|
|
store volatile i8 -42, i8* %ptr
|
|
br label %return
|
|
|
|
return:
|
|
ret void
|
|
}
|
|
|
|
|
|
; The 'test1_' prefixed functions test the basic scenario of inlining
|
|
; destroying dominator tree.
|
|
|
|
define void @test1_caller() {
|
|
; CHECK-LABEL: define void @test1_caller()
|
|
entry:
|
|
call void @callee()
|
|
; CHECK-NOT: @callee
|
|
ret void
|
|
; CHECK: ret void
|
|
}
|
|
|
|
|
|
; The 'test2_' prefixed functions test the scenario of not inlining preserving
|
|
; dominators.
|
|
|
|
define void @test2_caller() {
|
|
; CHECK-LABEL: define void @test2_caller()
|
|
entry:
|
|
call void @callee() noinline
|
|
; CHECK: call void @callee
|
|
ret void
|
|
; CHECK: ret void
|
|
}
|
|
|
|
|
|
; The 'test3_' prefixed functions test the scenario of not inlining preserving
|
|
; dominators after splitting an SCC into two smaller SCCs.
|
|
|
|
; This function ends up split into a separate SCC, which can cause its analyses
|
|
; to become stale if the splitting doesn't properly invalidate things. Also, as
|
|
; a consequence of being split out, test3_f is too large to inline by the time
|
|
; we get here.
|
|
define void @test3_g() {
|
|
; CHECK-LABEL: define void @test3_g()
|
|
entry:
|
|
; Create the second edge in the SCC cycle.
|
|
call void @test3_f()
|
|
; CHECK: call void @test3_f()
|
|
|
|
; Pull interesting CFG into this function.
|
|
call void @callee()
|
|
; CHECK-NOT: call void @callee()
|
|
|
|
ret void
|
|
; CHECK: ret void
|
|
}
|
|
|
|
; The second function gets visited first and we end up inlining everything we
|
|
; can into this routine. That splits test3_g into a separate SCC that is enqued
|
|
; for later processing.
|
|
define void @test3_f() {
|
|
; CHECK-LABEL: define void @test3_f()
|
|
entry:
|
|
; Create the first edge in the SCC cycle.
|
|
call void @test3_g()
|
|
; CHECK-NOT: @test3_g()
|
|
; CHECK: call void @test3_f()
|
|
|
|
; Pull interesting CFG into this function.
|
|
call void @callee()
|
|
; CHECK-NOT: call void @callee()
|
|
|
|
ret void
|
|
; CHECK: ret void
|
|
}
|