| Issue |
181821
|
| Summary |
[Inline] Unbounded inlining due to locally hot call sites
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
nikic
|
https://llvm.godbolt.org/z/jn5cedjGo
```llvm
; RUN: opt -S -passes=inline -locally-hot-callsite-threshold=525 < %s
; Explicit -locally-hot-callsite-threshold necessary due to some option handling peculiarities,
; this matches the default behavior when running the inliner as part of the full pipeline.
define void @caller() {
start:
br label %loop1
loop1:
%phi1 = phi i1 [ true, %start ], [ false, %loop2 ]
br i1 %phi1, label %loop2, label %exit
loop2:
%phi2 = phi i1 [ true, %loop1 ], [ false, %loop2.body ]
br i1 %phi2, label %loop2.body, label %loop1
loop2.body:
call void @callee1()
br label %loop2
exit:
ret void
}
define void @callee1() {
call void @callee2()
call void @callee2()
call void @callee2()
call void @callee2()
ret void
}
define void @callee2() {
call void @callee3()
call void @callee3()
call void @callee3()
call void @callee3()
ret void
}
define void @callee3() {
call void @callee4()
call void @callee4()
call void @callee4()
call void @callee4()
ret void
}
define void @callee4() {
call void @callee5()
call void @callee5()
call void @callee5()
call void @callee5()
ret void
}
declare void @callee5()
```
This ends up fully flattening the calls into the caller. The reason is that we have a doubly nested loop, which results in sufficiently high estimated relative block frequency that the inliner assumes these calls are locally hot. (The estimate is complete wrong in this case, but that's a different issue.)
However, this violates the inliners bottom-up inlining assumption, as we end up inlining calls which we previously declined to inline with a higher threshold. This can result in exponential inlining, like in this example.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
