Re: [PATCH] compiler_types: Introduce inline_for_performance
From: David Laight <hidden>
Date: 2026-01-18 22:33:22
Also in:
linux-mm, lkml, oe-kbuild-all
On Mon, 19 Jan 2026 02:36:18 +0800 kernel test robot [off-list ref] wrote:
Hi Eric,
...
vim +/__arch_xprod_64 +138 include/asm-generic/div64.h
461a5e51060c93 Nicolas Pitre 2015-10-30 125
f682b27c57aec2 Nicolas Pitre 2015-10-30 126 #ifndef __arch_xprod_64
f682b27c57aec2 Nicolas Pitre 2015-10-30 127 /*
f682b27c57aec2 Nicolas Pitre 2015-10-30 128 * Default C implementation for __arch_xprod_64()
f682b27c57aec2 Nicolas Pitre 2015-10-30 129 *
f682b27c57aec2 Nicolas Pitre 2015-10-30 130 * Prototype: uint64_t __arch_xprod_64(const uint64_t m, uint64_t n, bool bias)
f682b27c57aec2 Nicolas Pitre 2015-10-30 131 * Semantic: retval = ((bias ? m : 0) + m * n) >> 64
f682b27c57aec2 Nicolas Pitre 2015-10-30 132 *
f682b27c57aec2 Nicolas Pitre 2015-10-30 133 * The product is a 128-bit value, scaled down to 64 bits.
00a31dd3acea0f Nicolas Pitre 2024-10-03 134 * Hoping for compile-time optimization of conditional code.
f682b27c57aec2 Nicolas Pitre 2015-10-30 135 * Architectures may provide their own optimized assembly implementation.
f682b27c57aec2 Nicolas Pitre 2015-10-30 136 */
5f712d70e20a46 Eric Dumazet 2026-01-18 137 static inline_for_performance
d533cb2d2af400 Nicolas Pitre 2024-10-03 @138 uint64_t __arch_xprod_64(const uint64_t m, uint64_t n, bool bias)
f682b27c57aec2 Nicolas Pitre 2015-10-30 139 {
f682b27c57aec2 Nicolas Pitre 2015-10-30 140 uint32_t m_lo = m;
f682b27c57aec2 Nicolas Pitre 2015-10-30 141 uint32_t m_hi = m >> 32;
f682b27c57aec2 Nicolas Pitre 2015-10-30 142 uint32_t n_lo = n;
f682b27c57aec2 Nicolas Pitre 2015-10-30 143 uint32_t n_hi = n >> 32;
00a31dd3acea0f Nicolas Pitre 2024-10-03 144 uint64_t x, y;
f682b27c57aec2 Nicolas Pitre 2015-10-30 145
00a31dd3acea0f Nicolas Pitre 2024-10-03 146 /* Determine if overflow handling can be dispensed with. */
00a31dd3acea0f Nicolas Pitre 2024-10-03 147 bool no_ovf = __builtin_constant_p(m) &&
00a31dd3acea0f Nicolas Pitre 2024-10-03 148 ((m >> 32) + (m & 0xffffffff) < 0x100000000);Can that ever have got compiled? Won't the compiler complain about 0x100000000 being out of range? Lots of alternatives... If u128 exists this should probably just be: return ((u128)m * n + (bias ? m : 0)) >> 64; Which is probably the only alternative an architecture might provide (none do AFAICT). David