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 <20030723003212.1606C2A8B2 at canning.wemm.org>, Peter Wemm writes:
>"Poul-Henning Kamp" wrote:
>
>> That is the sort of thing which makes me belive that unless proven
>> beneficial (by one of the two criteria), inline is harmful.
>
>There is a great leap there.  Just because somebody isn't willing to spend
>considerable time to re-prove that the runtime improvement is still there
>to your satisfaction, that doesn't mean that it is harmful.

But because GCC ignored it previously, we also know that that nobody
has positive evidence that it is actually beneficial, right ?

>Take the i386 interrupt vector code.  Thats an example where it is massively
>inlined.  Having a non-inlined function that does all the calculations
>and bit shifting is much smaller in code size, but slower at runtime.

As I said in my previous email:  The first condition for adding an inline
is that some coder think it is a good idea.

You sound like you think I plan to rip out all "unproven" inlines
which add object code, that is not the case.

The ones I took out yesterday are the onces which GCC had ignored and
which therefore ipso facto were "unproven" _and_ added significant
amounts of object code if respected. 

I did that in order to get use closer to comfortably use -Werror
without a major text segment bloat.

Once we have -Werror back, I have other things to do.

But I certainly do hope that we have highlighted a problem here, and
I do hope that people are professional enough to accept that adding
inline in the future should be done based on more solid data than
pure speculation.

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