Re: [PATCH 0/4] list.h/treewide: get rid of no-op prefetch()

[Rasmus Villemoes <ravi@prevas.dk>]

On Mon, May 26 2025, Tom Rini <trini@konsulko.com> wrote:

> On Mon, May 26, 2025 at 11:10:33PM +0200, Rasmus Villemoes wrote:
>> On Sun, May 25 2025, Tom Rini <trini@konsulko.com> wrote:
>> 
>> > On Sun, May 25, 2025 at 10:07:56PM +0200, Rasmus Villemoes wrote:
>> >> 
>> >> :( so we've been relying on that prefetch() laundering away the
>> >> volatile.
>> >> 
>> >> Which really begs the question: Why, exactly, is it that gd even has
>> >> that volatile qualifier in the first place? 
>> >
>> > The answer is likely early 2000s GCC.
>> >
>> >> I'm 98% certain that we could drop that and get better code generation
>> >> and avoid a ton of places where we cast away that volatile which
>> >> shouldn't really be there anyway.
>> >
>> > It would be a good thing to experiment with now and maybe try for real
>> > in a near-future merge window.
>> 
>> So since it's declared per architecture I just tried with arm for now,
>> and this
>> 
>> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
>> index 45401d5e3c8..f7a47204b7c 100644
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>> @@ -133,9 +133,9 @@ static inline gd_t *get_gd(void)
>>  #else
>>  
>>  #ifdef CONFIG_ARM64
>> -#define DECLARE_GLOBAL_DATA_PTR                register volatile gd_t *gd asm ("x18")
>> +#define DECLARE_GLOBAL_DATA_PTR                register gd_t *gd asm ("x18")
>>  #else
>> -#define DECLARE_GLOBAL_DATA_PTR                register volatile gd_t *gd asm ("r9")
>> +#define DECLARE_GLOBAL_DATA_PTR                register gd_t *gd asm ("r9")
>>  #endif
>>  #endif
>>  
>> 
>> builds, boots to linux, and passes our test suite on our
>> beagleboneblack, imx7 SabreSD, RPi 3, RPi 4, RPi-cm4, wandboard,
>> imx8mp-evk; i.e. a good mix of 32 and 64 bit arm.
>
> That's a good set of datapoints, thanks. Do you want to post a real
> series at some point or should I do it and Suggested-by you? Thanks.

I'll do a series and let the azure CI chew on it before posting it for
real.

Rasmus