[PATCH] D98481: [Inliner] Do not inline mutual-recursive functions to avoid exponential size growth.
Wenlei He via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Mar 15 21:44:12 PDT 2021
wenlei added a comment.
In D98481#2628047 <https://reviews.llvm.org/D98481#2628047>, @hoy wrote:
> I got some numbers for SPEC2017 with AutoFDO + LTO. Timing wise no noticeable difference but there is difference in code size for some benchmarks which indicates less inlining with this patch. The difference is pretty big for `perlbench_s` I guess we don't see perf gap because recursive those functions are run a lot more times than the inlined times.
>
> After/Before (Code Size)
> 508.namd_r 100.00%
> 510.parest_r 100.00%
> 511.povray_r 97.89%
> 600.perlbench_s 89.68%
> 602.gcc_s 98.79%
> 605.mcf_s 100.00%
> 620.omnetpp_s 100.00%
> 623.xalancbmk_s 99.91%
> 625.x264_s 100.00%
> 631.deepsjeng_s 100.00%
> 638.imagick_s 99.55%
> 641.leela_s 100.00%
> 644.nab_s 100.00%
> 657.xz_s 100.00%
Do you have numbers on how many times the new check blocks inlining for each (if you move it to be the last check)? The code size number seems to be indicate that the change indeed impacts inlining quite a bit.
When the inline history was introduced in https://reviews.llvm.org/D36188, it was verified that it didn't block any inlining for spec.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D98481/new/
https://reviews.llvm.org/D98481
More information about the llvm-commits
mailing list