On Tue, Oct 27, 2015 at 3:55 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On Tue, Oct 27, 2015, at 15:32, Denys Vlasenko wrote: >> I have created a set of semi-automated scripts which look for >> large inlines in the kernel. >> >> Recently I taught it to even generate "git format-patch" patches >> (unfortunately, only for inlines in *.c files, not *.h), >> and here are they for 4.3.0-rc1 - i.e. current Linus tree. >> >> Submitting 300+ patches separately would amount to spamming, >> instead I encourage people to take a look at the patches >> on the Web: >> >> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/ >> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/README >> >> and in particular, at the set of most juicy patches, each of which >> shaves off more than 1000 bytes off its *.c module: >> >> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/patch_saves1000/ > > Does gcc -finline-limit=2000 somehow has the same effect?
I'm afraid that's not a solution. Any compiler-option-based fix would only work for inlines in *.c files, but at the same time it would replicate inlines in *.h files many times (once per module which calls the "auto-deinlined" inline). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/