From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF04B19F13F for ; Sat, 7 Feb 2026 22:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770503013; cv=none; b=XDaftfCXeAsXBBK5wGCFK0X1Rbm8z+CC68Ba9A7w7X0NLQd5WMODvU3clplCv/XcTjEV2h9++JLEqdxMTq22t5bELKBWcSlvBSigjn2nygXmrxVG08/VNiRcoihERivET10VZFKS3u99IkI1/j4ZklAYBYk8pGGe82FaHgjK7m0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770503013; c=relaxed/simple; bh=SCGrQDgOwCVY1ltWJ5MpLchNSS6LHzGvr86ALEZOgwI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=c7mcjpr8nd1qO8cuYUM9qeNpo9t/ufcqT29D0pgKfMVJpPjzETUW4vevQNDiteq9Mji/6OK2Ew1OHY96nqfvYTQT6JHEfktYF17j59JjROkLJNRW2fmE2kpefVL5TlyQwYR3fY6Ny3WVB8hMkhlNtJ+/5M4LTPybHe9yL/yPGic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=X9RSFo6y; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="X9RSFo6y" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-482f454be5bso35343375e9.0 for ; Sat, 07 Feb 2026 14:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770503011; x=1771107811; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=b7OkJvc77SNeLJDSGQeN0dk50207Tv4JwSujkK37gzg=; b=X9RSFo6y5ygeE17/63gv62c/Lg/K/3ms/zoKObu8LPHLWOuoSaTN19RLF1I2/lj6vn V1M6tA1LlV2rdHLdtlxmNHvLLAF38uPD9gme0SfCiu78mC5tlLILM7+HYNTAPy58KnGp xTNy0GWElbx0fZ2h5JdAhPNbsE9GXezT6QxWw8zcNEdTI92oACeaR2KxOG4orUZiyRnD DjaKuTJzGmFREcxr22WZRPMshSyqAmyV5cAJgbIFUpE4gWK3jR5ePCJPRKhuXdEtFWQ4 jlGbkJ+DB2mLPcPRbJbglZsMOAs9R+LDjOVhIDihERa/7+/dGAUwYc02WCuva5glw2CN cwlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770503011; x=1771107811; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=b7OkJvc77SNeLJDSGQeN0dk50207Tv4JwSujkK37gzg=; b=py3pgmXXgmNeiQjcLg+dR87flpdz7SD3XCu12zs/1PxCy7QCB67FGuvc0dStzXSfyD A12jHHNPB8eFimST2o78bcC48iQJS9j6KIbEzkeiMr3v5zWPHK2aHIPvq2hFUTlxZiLN DprM0RmPgqrUxTMZJxQ1Ysjdg4U+c1xQStmLupbXHYj/1KUMpbUPIjakGsJTYuuAQJeQ N0tVV7EbpdS5Q7DAAEct5nDH5OHF4MCQpzCCf/UPcuW7pclS1H9yPddbj+WiP8dJbjgM RtUNnu2c6Utbw747vyednTWHY7ORz+WPhskItjTqLUL0O+ONYKDD6r1U4rj1LvySkQpB MGhQ== X-Forwarded-Encrypted: i=1; AJvYcCUPhv69fWbb1mLv4xzWbmRZjNvKbs/r5sa49FLDxd7XfiAt6z+gVQbZ1nizeKAqOL3sJzeYtJjB5OUmII4=@vger.kernel.org X-Gm-Message-State: AOJu0YziCTpNpUEOitGTXSoqBDRkjR16CJwIT8uFiNnskWXPQCDPmzFg r7O8jC1PD1gOZJQeR49S4eE/H84x/vC4brRRgbs3yP+Py+W2IItpPxLv7I5UcQ== X-Gm-Gg: AZuq6aLJHi/4peSzc8aVMllJGt9WFzercTF/7j3XGV/R2T+LAx57i4q8zP+uNa2J4re 2Nx6eklcVITMML/y/+JGHwwQOClpxYkqSlXQdJiWz7Kz5AxafRrQOTLnDsZ0gx4DTDrJWzx0VkJ sxiSayzc5JMy332jSib4ETllfIXPiA/0vtIRVZvSfBA9nrTTecnkyIfeAoFiMX3Hq/8udJ2BZxW y/w1kNKEmJ/RgnTIIXAKFhPSM4esDiRWtqWNpRg47NQeR0Zl0Ku0FfXcXbmG/l+/FlMosZyakaJ aM5xaHzXJhJ1N5Vrzj1uc30s7MJ0F4SjSAHy21rK5vAeO5ViZdXk1Sw8Nhw6OcCd81k3rhUe1Bm hKIXYsgH0X3tixDWbLIjaZrslRViIKjUh8d/bRLuHErIkp76F82z1yDbDFbjlpOWAFmTW90+cvW yh/xCY3smEIgZGsLR30p/a0kQLi3ymhqXt0TWytajcXgzsbFuuSPPg X-Received: by 2002:a05:600c:a00f:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-483203aaae7mr99828385e9.5.1770503011163; Sat, 07 Feb 2026 14:23:31 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483206b8bbbsm233739465e9.3.2026.02.07.14.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Feb 2026 14:23:30 -0800 (PST) Date: Sat, 7 Feb 2026 22:23:29 +0000 From: David Laight To: Willy Tarreau Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH next] tools/nolibc: Optimise and common up number to ascii functions Message-ID: <20260207222329.38f7c6d6@pumpkin> In-Reply-To: References: <20260203151316.24506-1-david.laight.linux@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Sat, 7 Feb 2026 16:06:51 +0100 Willy Tarreau wrote: > Hi David, > > On Tue, Feb 03, 2026 at 03:13:15PM +0000, david.laight.linux@gmail.com wrote: > > From: David Laight > > > > Implement u[64]to[ah]_r() using a common function that uses multiply > > by reciprocal to generate the least significant digit first and then > > reverses the string. > > > > On 32bit this is five multiplies (with 64bit product) for each output > > digit. I think the old utoa_r() always did 36 multiplies and a lot > > of subtracts - so this is likely faster even for 32bit values. > > Definitely better for 64bit values (especially small ones). > > > > Clearly shifts are faster for base 16, but reversing the output buffer > > makes a big difference. > > > > Sharing the code reduces the footprint (unless gcc decides to constant > > fold the functions). > > Definitely helps vfprintf() where the constants get loaded and a single > > call is down. > > Also makes it cheap to add octal support to vfprintf for completeness. > > > > Signed-off-by: David Laight > > OK, I had a long series of tests on it, including with older compilers > going back to gcc-4.7 and on various archs. Except for code that would > previously only use utoh(), the new code is slightly smaller in the vast > majority of cases. And this combined with the added flexibility looks > like a good addition. The code is not trivial (as every time we're > dealing with number representation) but it's well documented, so I'm > personally fine with the change. > > I'm just having a few comments below: > > > -static __attribute__((unused)) > > -int utoh_r(unsigned long in, char *buffer) > > +#define __U64TOA_RECIP(base) ((base) & 1 ? ~0ull / (base) : (1ull << 63) / ((base) / 2)) > > Please rename this macro to have _NOBLIC_ as a prefix. Not hard :-) > > +#if defined(__SIZEOF_INT128__) && !defined(__mips__) > > Out of curiosity, why !mips ? I tried with -mabi=64 and the function size > dropped from 0x120 to 0xc0 (lost 1/3 of its size). I think it is mips, some of the older versions of gcc emit a library call even though the cpu has the required instruction. Cropped up in the mul_u64_u64_div_u64 code. I could look up the versions and add a comment. > > > + q = ((unsigned __int128)in * recip) >> 64; > > +#else > (...) > > Once the macro is renamed, feel free to add: > > Acked-by: Willy Tarreau Thanks. David > > Thanks! > Willy