[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