mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros
@ 2026-10-23 16:31 Tzu-Ching Yang
  2026-10-24 18:15 ` Eric Biggers
  0 siblings, 1 reply; 3+ messages in thread
From: Tzu-Ching Yang @ 2026-10-23 16:31 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Jason A. Donenfeld, Ard Biesheuvel, Alexander Lobakin,
	Jose E. Marchesi, Jakub Kicinski, Andrew Morton, Simon Horman,
	Maciej Fijalkowski, David Laight, linux-crypto, linux-kernel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros
  2026-10-23 16:31 [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros Tzu-Ching Yang
@ 2026-10-24 18:15 ` Eric Biggers
  2026-10-24 18:27   ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Biggers @ 2026-10-24 18:15 UTC (permalink / raw)
  To: Tzu-Ching Yang
  Cc: Jason A. Donenfeld, Ard Biesheuvel, Alexander Lobakin,
	Jose E. Marchesi, Jakub Kicinski, Andrew Morton, Simon Horman,
	Maciej Fijalkowski, David Laight, linux-crypto, linux-kernel

On Sat, Oct 24, 2026 at 12:31:08AM +0800, Tzu-Ching Yang wrote:
> 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>

Reviewed-by: Eric Biggers <ebiggers@kernel.org>

> 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)?

Either way is fine with me.  It's one of the unowned files, which are
always problematic.  If Andrew hasn't taken it by the time -rc1 rolls
around, I'll apply it to libcrypto-next: it's at least somewhat related,
given that lib/crypto/ is one of the few users of this file.

- Eric

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros
  2026-10-24 18:15 ` Eric Biggers
@ 2026-10-24 18:27   ` Andrew Morton
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2026-10-24 18:27 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Tzu-Ching Yang, Jason A. Donenfeld, Ard Biesheuvel,
	Alexander Lobakin, Jose E. Marchesi, Jakub Kicinski,
	Simon Horman, Maciej Fijalkowski, David Laight, linux-crypto,
	linux-kernel

On Sat, 24 Oct 2026 11:15:20 -0700 Eric Biggers <ebiggers@kernel.org> wrote:

> On Sat, Oct 24, 2026 at 12:31:08AM +0800, Tzu-Ching Yang wrote:
> > 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>
> 
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> 
> > 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)?
> 
> Either way is fine with me.  It's one of the unowned files, which are
> always problematic.  If Andrew hasn't taken it by the time -rc1 rolls
> around, I'll apply it to libcrypto-next: it's at least somewhat related,
> given that lib/crypto/ is one of the few users of this file.

That sounds good.

I'm only looking at bugfixes at present.  Non-fixes get parked for
consideration after -rc1.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-24 18:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-23 16:31 [PATCH v2] unroll: Drop the unused unrolled and unrolled_none macros Tzu-Ching Yang
2026-10-24 18:15 ` Eric Biggers
2026-10-24 18:27   ` Andrew Morton

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®