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 <20030723012048.GB61884 at athlon.pn.xcllnt.net>, Marcel Moolenaar writ
es:

>> >Inlining a function that has only 1 caller, and the call is on
>> >a cold path (ie a nested if or else that's almost never executed)
>> 
>> Why on earth would you even think about inlining in that case ?
>
>That's not the point. You make unqualified general statements
>that smaller code yields faster execution (ipso facto).

Ok, since you guys are so insistent on misunderstanding me:

The algorithm I would like to see implemented as a pre-commit check
for the __inline* keywords are:


[1]	if (programmer thinks inline might be useful) {
		try compiling with inline;
[2]		if (object code smaller) {
			/* inline is beneficial */
			commit it;
			return;
		} 
		run benchmark;
[3]		if (code runs faster) {
			/* inline is beneficial */
			commit it;
			return;
		}
	}
	/* inline not proven beneficial */
	return;

Please notice that there are *3* tests involved and that we
must hope that test [1] prevents a pessimization like the
one you proposed above.

Please also notice that we are not talking about what the compiler
autonomously decides to inline, unroll etc, only what the necessary
burden-of-proof the programmer must lift before committing an
inline.

Criteria [2] was meant as a shortcut for [3] but if you have so much
against it, I will happily drop it, forcing you to prove with real
world data that each and every inline is actually beneficial.

And no, it wasn't my intent that this needs to be a formal process
with paperwork and subcommittees.

-- 
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.