From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 D3B3C39CCE1 for ; Wed, 15 Jul 2026 05:33:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784093620; cv=none; b=OL8Td1Y4GKK5+4kere+rpmOeG1OcLuWffKFvy+ktByeEBC5lFl9+pSi51cN50O5XkTKPq3jAVhBCa8olqGeXfMdCq2O7EpIAajXM7CHB8mWnWtXVqLGmbl9omGaXxjELnD8oUvQQSqW21BwKWkLjbKxUv16BSdrst6V04Ek/f1U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784093620; c=relaxed/simple; bh=ZhH9WsN1jN1hMKK3Frp9YgIp9hEHvPoyDOlK+Gv7Qgs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dB9zGbXa3tI/9h7ozC9vti1Ld54OvTi/yScVCG/fhn4la/OPim2vGdyNYioRu9cKPZTVngL7Dg+Wkauk6+ID1NZMKbd65ROn9UhfIuSDp4xZDmyBXUbCQztVZAPxPpHRdjOLk6hBPsFrRN3yF/p34UimlywWLz3Jsi0antuFEa0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZIF6cizh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZIF6cizh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6575B1F000E9; Wed, 15 Jul 2026 05:33:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784093619; bh=eLP+QKELNwSRheK6Eb3NeNwzp7kapDDyF0LqlE2v06k=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=ZIF6cizh+ctMTe0/FM3DFHdWfqFx3J9qw1fh7H6mr8CDDRKKvCixXKKE1EV758j5n Tp/NWsVXKbisZp1iTxmieuI9pPTWcGjDcVh+lD3dblGGF2tV44uVzbbhNpiJMJYjk9 wX5eDb9I76lnx+IonS3mnCrpqc7s9l7wxiCvWc0TVX/a5l30ySM4hY2uUh/XulJAY1 oQxLIjScSmJsEVGR9eJ6oiSDagxUBCX4rzzYFUr+vZjF+FVEhJvE36hpZrdm4HwGeT QsvdQxA52QTZJWiPd9PZQcu4t8nlNp61StDN/Y2Wc/NRTEeP1rQgfd4LTX8hdqVyzL sZKMdQ2el5e2A== Message-ID: <7d0d6db6-d4d9-41df-bc28-6c7c1d3f57cf@kernel.org> Date: Wed, 15 Jul 2026 07:33:34 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] container_of: refactors To: Greg Kroah-Hartman Cc: Andrew Morton , Rasmus Villemoes , Sakari Ailus , Nick Desaulniers , Alexander Lobakin , Arnd Bergmann , David Sterba , Ivo van Doorn , Alexey Dobriyan , linux-kernel@vger.kernel.org References: <20260714-containerof_refactor-v1-0-b5c31164d2ad@kernel.org> <2026071514-sulfur-skydiver-7604@gregkh> From: Vincent Mailhol Content-Language: en-US Autocrypt: addr=mailhol@kernel.org; keydata= xjMEZluomRYJKwYBBAHaRw8BAQdAf+/PnQvy9LCWNSJLbhc+AOUsR2cNVonvxhDk/KcW7FvN JFZpbmNlbnQgTWFpbGhvbCA8bWFpbGhvbEBrZXJuZWwub3JnPsKZBBMWCgBBFiEE7Y9wBXTm fyDldOjiq1/riG27mcIFAmdfB/kCGwMFCQp/CJcFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcC F4AACgkQq1/riG27mcKBHgEAygbvORJOfMHGlq5lQhZkDnaUXbpZhxirxkAHwTypHr4A/joI 2wLjgTCm5I2Z3zB8hqJu+OeFPXZFWGTuk0e2wT4JzjgEZx4y8xIKKwYBBAGXVQEFAQEHQJrb YZzu0JG5w8gxE6EtQe6LmxKMqP6EyR33sA+BR9pLAwEIB8J+BBgWCgAmFiEE7Y9wBXTmfyDl dOjiq1/riG27mcIFAmceMvMCGwwFCQPCZwAACgkQq1/riG27mcJU7QEA+LmpFhfQ1aij/L8V zsZwr/S44HCzcz5+jkxnVVQ5LZ4BANOCpYEY+CYrld5XZvM8h2EntNnzxHHuhjfDOQ3MAkEK In-Reply-To: <2026071514-sulfur-skydiver-7604@gregkh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15/07/2026 at 06:54, Greg Kroah-Hartman wrote: > On Tue, Jul 14, 2026 at 08:18:00PM +0200, Vincent Mailhol wrote: >> This series refactors the container_of() function-like macro to improve >> readability and remove a sparse/W=2 shadow warning. Further details in >> each patch. >> >> While I was expecting this series to be boring and purely cosmetic, the >> bloat-o-meter stats gave some unexpected results: >> >> $ ./scripts/bloat-o-meter vmlinux7.2-rc3_before.o vmlinux7.2-rc3_after.o >> add/remove: 0/0 grow/shrink: 133/93 up/down: 5914901/-14344137 (-8429236) >> < ... 227 lines redacted > >> Total: Before=2641674349, After=2633245113, chg -0.32% >> >> (done on v7.2-rc3 with GCC 15.3.0 on an x86_64 defconfig) >> >> Upon analysis, this change in size can be tracked down to places where >> container_of() is used in combination with __builtin_constant_p(). >> >> Here is a minimal reproducer: >> >> struct foo { >> int a; >> }; >> >> #define to_foo(a_ptr) container_of(a_ptr, struct foo, a) >> >> int f(int *a) >> { >> return __builtin_constant_p(to_foo(a)->a) || a; >> } >> >> The assembly code before this series...: >> >> xor eax, eax >> test rdi, rdi >> setne al >> ret >> >> ...and after: >> >> mov eax, 1 >> ret >> >> Link: https://godbolt.org/z/fenbGexjY >> >> __builtin_constant_p(to_foo(a)->a) evaluates to false but gives the >> optimiser the hint that pointer a is not NULL because of the >> assumption that no undefined behaviour occurs. With this, the >> expression: >> >> __builtin_constant_p(to_foo(a)->a) || a >> >> could be evaluated as true by the optimiser. >> >> But the small variation in container_of() makes it that the optimiser >> currently misses this optimisation but manages to do it after the >> simplification of patch #3 of this series. >> >> When __builtin_constant_p()'s argument is not trivially a compile time >> constant, the result of __builtin_constant_p() comes late in the >> evaluation process. And if it comes too late, after some other >> optimisations were already done, the compiler will not retry and simply >> miss these optimisations. >> >> Note that the above example is very fragile and the results shown in >> the godbolt link might not be reproducible under very small >> variations. >> >> Signed-off-by: Vincent Mailhol > > "fun" thing is, clang gets this right without your change, so this only > seems to help the gcc users. Indeed. I forgot to mention it, but I also observed that clang is not impacted by these weird __builtin_constant_p() intricacies. One lesson learned it that in GCC __builtin_constant_p() can become an optimisation killer. > Anyway, very nice optimizations, thanks for this! I'll queue these up > later today. Thanks! Yours sincerely, Vincent Mailhol