From owner-cvs-src-old@FreeBSD.ORG Sat Jan 17 18:57:31 2009 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F640106564A for ; Sat, 17 Jan 2009 18:57:31 +0000 (UTC) (envelope-from das@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA358FC17 for ; Sat, 17 Jan 2009 18:57:31 +0000 (UTC) (envelope-from das@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n0HIvVCM012362 for ; Sat, 17 Jan 2009 18:57:31 GMT (envelope-from das@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n0HIvV5Z012361 for cvs-src-old@freebsd.org; Sat, 17 Jan 2009 18:57:31 GMT (envelope-from das@repoman.freebsd.org) Message-Id: <200901171857.n0HIvV5Z012361@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to das@repoman.freebsd.org using -f From: David Schultz Date: Sat, 17 Jan 2009 18:57:12 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/lib/libc/stdio vfprintf.c vfwprintf.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 18:57:31 -0000 das 2009-01-17 18:57:12 UTC FreeBSD src repository Modified files: lib/libc/stdio vfprintf.c vfwprintf.c Log: SVN rev 187369 on 2009-01-17 18:57:12Z by das When f[w]printf() is called on an unbuffered file like stdout, it sets up a fake buffered FILE and then effectively calls itself recursively. Unfortunately, gcc doesn't know how to do tail call elimination in this case, and actually makes things worse by inlining __sbprintf(). This means that f[w]printf() to stderr was allocating about 5k of stack on 64-bit platforms, much of which was never used. I've reorganized things to eliminate the waste. In addition to saving some stack space, this improves performance in my tests by anywhere from 5% to 17% (depending on the test) when -fstack-protector is enabled. I found no statistically significant performance difference when stack protection is turned off. (The tests redirected stderr to /dev/null.) Revision Changes Path 1.86 +12 -7 src/lib/libc/stdio/vfprintf.c 1.37 +11 -7 src/lib/libc/stdio/vfwprintf.c