From: Tzu-Ching Yang <shingekinocore@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Ard Biesheuvel <ardb@kernel.org>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>,
Jakub Kicinski <kuba@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Simon Horman <horms@kernel.org>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
David Laight <david.laight.linux@gmail.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros
Date: Sat, 24 Oct 2026 00:31:08 +0800 [thread overview]
Message-ID: <20261023163108.2042675-1-shingekinocore@gmail.com> (raw)
unrolled and unrolled_none are object-like macros with lower-case
names, and neither has had a user since commit c6594d642717 ("unroll:
add generic loop unroll helpers") added them in February 2025.
The name unrolled also breaks code that uses it for something else. On
GCC the macro expands to an empty _Pragma(), so a function parameter
named unrolled compiles with only -Wunknown-pragmas warnings (errors
only with CONFIG_WERROR) and silently loses its name:
int add(int unrolled, int x) { return unrolled + x; }
builds as "return x;" with GCC 11 to 16 (GCC 8 to 10 and Clang reject
it).
Drop both macros, and retitle the kernel-doc comment from unrolled to
unrolled_count(), the macro its usage example shows. unrolled_full and
unrolled_count() stay; any clash with their names fails to build
instead of compiling silently.
Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Link: https://lore.kernel.org/all/3c25921c-7bdf-4edd-ba06-838dd1765db6@intel.com/
Signed-off-by: Tzu-Ching Yang <shingekinocore@gmail.com>
---
v2: drop the two unused macros instead of making all three
function-like (Alexander Lobakin).
v1: https://lore.kernel.org/all/20261016025613.2690485-1-shingekinocore@gmail.com/
Eric, this version no longer touches lib/crypto/. Would you still
take it through libcrypto-next, or should it go through Andrew's -mm
tree (unroll.h has no MAINTAINERS entry)?
Testing: an x86_64 defconfig build with the includers of
<linux/unroll.h> enabled (BLAKE2b/s, LSMs, IMA/EVM, BPF LSM, vhost,
i40e/ice/idpf; no debug info) gives byte-identical objects, modules and
vmlinux before and after, with GCC 11.5, GCC 16.2 and Clang 23. In a
file that includes only <linux/unroll.h>, a variable, member or
parameter named unrolled or unrolled_none now builds without warnings
with GCC 8.1 to 16.2 and Clang 17 to 23.
Based on libcrypto-next (20ec6916d871); applies as is to
next-20261022, which has no users of the two macros either.
include/linux/unroll.h | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/include/linux/unroll.h b/include/linux/unroll.h
index 186b71de7..d027b37f6 100644
--- a/include/linux/unroll.h
+++ b/include/linux/unroll.h
@@ -16,7 +16,8 @@
#endif
/**
- * unrolled - loop attributes to ask the compiler to unroll it
+ * unrolled_count() - loop attribute to ask the compiler to unroll it
+ * @n: unroll each @n iterations of the loop
*
* Usage:
*
@@ -34,12 +35,6 @@
* provides best performance and object code size.
* Available only on Clang and GCC 8.x onwards.
*/
-
-/* Ask the compiler to pick an optimal unroll count, Clang only */
-#define unrolled \
- __pick_unrolled(clang loop unroll(enable), /* nothing */)
-
-/* Unroll each @n iterations of the loop */
#define unrolled_count(n) \
__pick_unrolled(clang loop unroll_count(n), GCC unroll n)
@@ -47,10 +42,6 @@
#define unrolled_full \
__pick_unrolled(clang loop unroll(full), GCC unroll 65534)
-/* Never unroll the loop */
-#define unrolled_none \
- __pick_unrolled(clang loop unroll(disable), GCC unroll 1)
-
#define UNROLL(N, MACRO, args...) CONCATENATE(__UNROLL_, N)(MACRO, args)
#define __UNROLL_0(MACRO, args...)
base-commit: 20ec6916d8712e84d58e8c688a25cd368ddeb82b
--
2.34.1
reply other threads:[~2026-10-23 16:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261023163108.2042675-1-shingekinocore@gmail.com \
--to=shingekinocore@gmail.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=ardb@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=ebiggers@kernel.org \
--cc=horms@kernel.org \
--cc=jose.marchesi@oracle.com \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.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
all inboxes | Powered by JetHome®