From owner-cvs-all@FreeBSD.ORG Tue Jul 22 22:40:14 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1500737B401; Tue, 22 Jul 2003 22:40:14 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 095D043F3F; Tue, 22 Jul 2003 22:40:13 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6N5eCV3037045; Wed, 23 Jul 2003 05:40:12 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6N5eB5H019807; Wed, 23 Jul 2003 07:40:11 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 17:32:12 PDT." <20030723003212.1606C2A8B2@canning.wemm.org> Date: Wed, 23 Jul 2003 07:40:11 +0200 Message-ID: <19806.1058938811@critter.freebsd.dk> Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 05:40:14 -0000 In message <20030723003212.1606C2A8B2@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@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.