Re: [PATCH] unroll: Make unrolled, unrolled_full and unrolled_none function-like

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Tzu-Ching Yang <shingekinocore@gmail.com>
Date: Thu, 22 Oct 2026 19:09:59 +0800

> On Thu, Oct 22, 2026 at 10:01:40AM +0100, David Laight wrote:
>> Is it possible to make the syntax:
>> 	unrolled_for(....)
>>
>> Or is that made 'all hard and difficult' because he setting is sticky?
> 
> The pragma binds only to the loop that follows it, so it can go inside
> the macro:
> 
> #define unrolled_full_for(...) \
> 	__pick_unrolled(clang loop unroll(full), GCC unroll 65534) \
> 	for (__VA_ARGS__)
> 
> 	unrolled_full_for (int i = 0, j = 7; i < 8; i++, j--)
> 		s += a[i] * b[j];
> 
> GCC 8 to 16 and Clang 17 to 23 unroll this fully, and the same works
> with break and continue in the body, nested loops and a loop inside
> another macro. The count form has the same shape:
> 
> 	unrolled_count_for (4, int i = 0; i < n; i++)
> 		s += a[i];
> 
> As a fourth option, the _for forms would replace the four unrolled*
> macros: no clash with identifiers, and the loop reads like
> for_each_*(); the cost is a new loop spelling at every user. Olek,
> Eric, would you prefer this over options 1 to 3 from my earlier reply?

I had considered this option in the past, but IIRC the unrolled
attribute can also apply to `while` etc, this would limit it to
`for` only.

Honestly I think I'd just drop the unused versions (`unrolled` and
`unrolled_none`) since they've gained no users for their entire lifetime
(sorta understandable since the former relies too much on the compiler
and the latter makes sense only in some very constrained environments
where usually, the related compiler flags are used globally instead).

> 
> Thanks,
> Tzu-Ching

Thanks,
Olek