cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[Poul-Henning Kamp]

In message <20030722231656.GA9715 at HAL9000.homeunix.com>, David Schultz writes:

Please remember that the problem at hand is getting -Werror back
on the kernel so we can catch issues like the warning in umtx.

We could either do that by lobotomizing the warning in the compiler
or by setting the limit high enough to inline everything so marked.

Since the warning has indeed pointed out a fair number of bogus
inlines, the first option did not seem attractive.

>Actually, it might be interesting to make a list of all the
>functions in the kernel that contain inline calls sorted by the
>bytes of bloat.  Then for all those grey areas, developers could
>be asked to look at the list and reconsider their use of inlines,
>and you wouldn't have to waste your talent trying to evaluate each one.

This is more or less what I have been spending my day doing, only
I used the GCC metric as indication to target the most likely
offenders.

My experiments have shown that if we had just raised the limit high
enough to inline everything that we have marked as inline, the
GENERIC kernel text segment would have grown by more than 100 k.

The inlines I have removed today have all been inlines which GCC
has previously ignored and which added significant code segment
size, typically 2k+.

You can see some of my raw data here: http://phk/misc/inline.txt

The first table should be self explanatory.

The table at the bottom has three fields:
	last limit where GCC refused the inlining
	name of functions
	calls to funcion.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.