[PATCH] D98481: [Inliner] Do not inline mutual-recursive functions to avoid exponential size growth.
Hongtao Yu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Mar 15 22:44:03 PDT 2021
hoy added a comment.
In D98481#2628055 <https://reviews.llvm.org/D98481#2628055>, @wenlei wrote:
> 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.
Callsite inlining are good counters. For those benchmarks affected, inlined callsites vs non-inlined callsites due to this change are:
inlined callsites recursive callsites
511.povray_r 3178 603
600.perlbench_s 4577 2139
602.gcc_s 46125 726
623.xalancbmk_s 15573 79
638.imagick_s 7719 61
Apparently, `perlbench_s` has a lot less inlining.
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