All of lore.kernel.org
 help / color / mirror / Atom feed
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: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 16:31 Tzu-Ching Yang [this message]
2026-10-24 18:15 ` [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros Eric Biggers
2026-10-24 18:27   ` Andrew Morton

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.