From: Nathan Chancellor <nathan@kernel.org>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: Miguel Ojeda <ojeda@kernel.org>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Juergen Christ <jchrist@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Sven Schnelle <svens@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 1/3] Compiler Attributes: Add __assume macro
Date: Wed, 10 Sep 2025 18:32:43 -0700 [thread overview]
Message-ID: <20250911013243.GA292340@ax162> (raw)
In-Reply-To: <20250910151216.646600-2-hca@linux.ibm.com>
Hi Heiko,
On Wed, Sep 10, 2025 at 05:12:14PM +0200, Heiko Carstens wrote:
> Make the statement attribute "assume" with a new __assume macro available.
>
> This allows compilers to generate better code, however code which makes use
> of __assume must be written as if the compiler ignores the hint. Otherwise
> this may lead to subtle bugs if code is compiled with compilers which do
> not support the attribute.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> include/linux/compiler_attributes.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index c16d4199bf92..16c3d4a865e2 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -54,6 +54,22 @@
> */
> #define __always_inline inline __attribute__((__always_inline__))
>
> +/*
> + * Beware: Code which makes use of __assume must be written as if the compiler
> + * ignores the hint. Otherwise this may lead to subtle bugs if code is compiled
> + * with compilers which do not support the attribute.
It may be worth noting that careful analysis should be performed when
adding this attribute since clang's documentation [1] (more on that
below...) notes that it could hurt optimizations just as much as it
could help it.
> + *
> + * Optional: only supported since GCC >= 13.1, clang >= 12.0
> + *
> + * gcc: https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute
> + * clang: https://clang.llvm.org/docs/AttributeReference.html#assume
Looking at this link sent me down a bit of a rabbit hole :) Prior to
Clang 19.1.0 [2], assume was an OpenMP attribute, which has completely
different semantics and errors out when used in the way the series does:
In file included from kernel/bounds.c:13:
In file included from include/linux/log2.h:12:
In file included from include/linux/bitops.h:67:
arch/s390/include/asm/bitops.h:173:12: error: expected string literal as argument of '__assume__' attribute
173 | __assume(bit <= 64);
| ^
Unfortunately, I think __assume will need to be handled in the compiler
specific headers :/
[1]: https://clang.llvm.org/docs/AttributeReference.html#id13
[2]: https://github.com/llvm/llvm-project/commit/c44fa3e8a9a44c2e9a575768a3c185354b9f6c17
Cheers,
Nathan
> + */
> +#if __has_attribute(assume)
> +# define __assume(expr) __attribute__((__assume__(expr)))
> +#else
> +# define __assume(expr)
> +#endif
> +
> /*
> * The second argument is optional (default 0), so we use a variadic macro
> * to make the shorthand.
> --
> 2.48.1
>
next prev parent reply other threads:[~2025-09-11 1:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 15:12 [PATCH 0/3] s390: Fix and optimize __flogr() inline assembly Heiko Carstens
2025-09-10 15:12 ` [PATCH 1/3] Compiler Attributes: Add __assume macro Heiko Carstens
2025-09-11 1:32 ` Nathan Chancellor [this message]
2025-09-11 14:56 ` Heiko Carstens
2025-09-11 18:44 ` Nathan Chancellor
2025-09-11 19:04 ` Miguel Ojeda
2025-09-11 20:42 ` Nathan Chancellor
2025-09-11 18:56 ` Miguel Ojeda
2025-09-11 18:59 ` Miguel Ojeda
2025-09-12 10:25 ` Heiko Carstens
2025-09-10 15:12 ` [PATCH 2/3] s390/bitops: Limit return value range of __flogr() Heiko Carstens
2025-09-11 7:44 ` Juergen Christ
2025-09-11 13:24 ` kernel test robot
2025-09-10 15:12 ` [PATCH 3/3] s390/bitops: Remove volatile qualifier from flogr() inline assembly Heiko Carstens
2025-09-11 7:45 ` Juergen Christ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250911013243.GA292340@ax162 \
--to=nathan@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jchrist@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox