1; When an SCC got split due to inlining, we have two mechanisms for reprocessing the updated SCC, first is UR.UpdatedC 2; that repeatedly rerun the new, current SCC; second is a worklist for all newly split SCCs. We need to avoid rerun of 3; the same SCC when the SCC is set to be processed by both mechanisms back to back. In pathological cases, such extra, 4; redundant rerun could cause exponential size growth due to inlining along cycles. 5; 6; The test cases here illustrates potential redundant rerun and how it's prevented, however there's no extra inlining 7; even if we allow the redundant rerun. In real code, when inliner makes different decisions for different call sites 8; of the same caller-callee edge, we could end up getting more recursive inlining without SCC mutation. 9; 10; REQUIRES: asserts 11; RUN: opt < %s -passes='cgscc(inline)' -inline-threshold=500 -debug-only=cgscc -S 2>&1 | FileCheck %s 12 13; CHECK: Running an SCC pass across the RefSCC: [(test1_a, test1_b, test1_c)] 14; CHECK: Enqueuing the existing SCC in the worklist:(test1_b) 15; CHECK: Enqueuing a newly formed SCC:(test1_c) 16; CHECK: Switch an internal ref edge to a call edge from 'test1_a' to 'test1_c' 17; CHECK: Switch an internal ref edge to a call edge from 'test1_a' to 'test1_a' 18; CHECK: Re-running SCC passes after a refinement of the current SCC: (test1_c, test1_a) 19; CHECK: Skipping redundant run on SCC: (test1_c, test1_a) 20 21declare void @external(i32 %seed) 22 23define void @test1_a(i32 %num) { 24entry: 25 call void @test1_b(i32 %num) 26 call void @external(i32 %num) 27 ret void 28} 29 30define void @test1_b(i32 %num) { 31entry: 32 call void @test1_c(i32 %num) 33 call void @test1_a(i32 %num) 34 call void @external(i32 %num) 35 ret void 36} 37 38define void @test1_c(i32 %num) #0 { 39 call void @test1_a(i32 %num) 40 ret void 41} 42 43attributes #0 = { noinline nounwind optnone } 44