On Mon, May 26 2025, Tom Rini <tr...@konsulko.com> wrote:
> On Mon, May 26, 2025 at 11:10:33PM +0200, Rasmus Villemoes wrote:
>> On Sun, May 25 2025, Tom Rini <tr...@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
