From owner-cvs-all@FreeBSD.ORG Tue Jul 22 22:31:16 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 46FBD37B401; Tue, 22 Jul 2003 22:31:16 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB5343F93; Tue, 22 Jul 2003 22:31:15 -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 h6N5VDV3036913; Wed, 23 Jul 2003 05:31:13 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 h6N5VC5H019768; Wed, 23 Jul 2003 07:31:12 +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 18:20:48 PDT." <20030723012048.GB61884@athlon.pn.xcllnt.net> Date: Wed, 23 Jul 2003 07:31:12 +0200 Message-ID: <19767.1058938272@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:31:16 -0000 In message <20030723012048.GB61884@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@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.