From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7044C2C08C8 for ; Sun, 8 Feb 2026 14:44:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770561879; cv=none; b=jaZkkrcFgMPJ/0YrYtyF5WM/X4N+JvlBc8t2z4wvSIi7JlGxbUR9iUvvZ0PNnLU19uS8pRRk87JR+gURbMY87/dbQOfoKffYO5DG5tXw76B40rGsHTbTaI++lRa4Kc01IkYepu0+y0SRBhgD+XYQcRoVK8FXmLfP/lXBZORY3Qk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770561879; c=relaxed/simple; bh=7hvh77GXgCBHfFoZ5xDK8yyZJdPhP0dKo+temgGJhLA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FtfRAHcpbSZXLTE5R4D7taaF6XW96G1//48FqZhchDURLxFEeFLILMBoAuai+VKH0NkRE0rUD2wzIQIPkRl/k6nQTMXM9nvG6JpuuSbQeoAQc+8vBDdmRVCB6d8xyF0deUQ8JJioptxQ6OupwOxdzgYKrpH5VfRRY+RdKzALSyE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=sWVn2HK9; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="sWVn2HK9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1770561869; bh=1qEHGrRIr6vuJnBYOJ7+/z8+8K2pREY4rAKcx/L/Zps=; h=From:Message-ID:From; b=sWVn2HK9B06lmzu58YuZ2ayklZ9o7VcmDr+HQKXl17/pkD5x6sns//RFiJ21NOcvE B99WPf5poGugC/PZA2+5jfcfr+7bV4/TrstOB3DCr/MFc/6eSk5/cZvnRJya7zx1GY GglSMved7h36V5On7LeW0g8OTlpMbl3u7b0d9lMA= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id C5844C0A6F; Sun, 08 Feb 2026 15:44:29 +0100 (CET) Date: Sun, 8 Feb 2026 15:44:29 +0100 From: Willy Tarreau To: David Laight Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v2 next 05/11] tools/nolibc/printf: Simplify __nolibc_printf() Message-ID: References: <20260206191121.3602-1-david.laight.linux@gmail.com> <20260206191121.3602-6-david.laight.linux@gmail.com> <20260207235019.40f82fca@pumpkin> <20260208122031.355dc213@pumpkin> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260208122031.355dc213@pumpkin> Hi David, On Sun, Feb 08, 2026 at 12:20:31PM +0000, David Laight wrote: > On Sat, 7 Feb 2026 23:50:19 +0000 > David Laight wrote: > > > On Sat, 7 Feb 2026 21:05:42 +0100 > > Willy Tarreau wrote: > > > > > On Fri, Feb 06, 2026 at 07:11:15PM +0000, david.laight.linux@gmail.com wrote: > > > > From: David Laight > > > > > > > > Move the check for the length modifiers into the format processing > > > > between the field width and conversion specifier. > > > > This lets the loop be simplified and a 'fast scan' for a format start > > > > used. > > > > > > > > If an error is detected (eg an invalid conversion specifier) then > > > > copy the invalid format to the output buffer. > > > > > > > > Reduces code size by about 10% on x86-64. > > > > > > I'm surprised, because for me it's the opposite: > > > > > > $ size hello-patch* > > > text data bss dec hex filename > > > 1859 48 24 1931 78b hello-patch1 > > > 2071 48 24 2143 85f hello-patch2 > > > 2091 48 24 2163 873 hello-patch3 > > > 2422 48 24 2494 9be hello-patch4 > > > > > > The whole program grew by almost 16%, and that's a 30% increase since > > > the first patch. This is with gcc 15 -Oz. aarch64 however decreased by > > > 15 bytes since previous patch. > > > > > > I have not figured what makes this change yet, I'm still digging. > > > > Running scripts/bloat-o-meter will give more detail. > > > > > Willy > > > > I'm using gcc 12.2 and just running 'make O=xxx' for the test program. > > The object looks like what I'd expect, so might be -O2. > > > > Is it constant folding the #defines. > > For me it generating the (1 << (c & 31)) & 0xxxxx as you might hope. > > Further thoughts: > > On some of the builds I've done gcc duplicated the code following an 'if' > into both the 'then' and 'else' clauses. > This isn't good for code size. That's common in loops for example. That's also one reason for avoiding "else" statements in compact code. However here I finally found what inflates the code, when disassembling the whole function: with the move of the multiple "if" statements, recent compilers managed to turn it into a jump table, that considerably inflates .rodata and the function as well. By passing -fno-jump-tables, the size drops by ~500 bytes: text data bss dec hex filename 2422 48 24 2494 9be hello-patch4 1917 48 24 1989 7c5 hello-patch4-alt <--- Building with gcc before 13 also avoids this table and explains why you had better code with gcc-12. I also noticed that we can reduce the loop by ~40 bytes by moving the literal copy after after the block that deals with format sequences, because it eases comparisons, but that's no big deal for now since your subsequent patches are going to change all that. At least I wanted to understand what was causing this difference for us both, and whether it risked remaining definitive or not, so now this patch is OK to me. Acked-by: Willy Tarreau Willy