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

[Tom Rini]

On Sun, May 25, 2025 at 10:07:56PM +0200, Rasmus Villemoes wrote:
> On Thu, May 22 2025, Tom Rini <trini at konsulko.com> wrote:
> 
> > On Wed, May 07, 2025 at 02:12:42PM +0200, Rasmus Villemoes wrote:
> >
> >> While looking through list.h, I saw that the regular list_* helpers
> >> (and one of the hlist_* ones) still contain the prefetch() that was
> >> removed in linux 14 years ago. It doesn't do anything, but makes the
> >> macros harder to read, so get rid of it, and the fallback, no-op
> >> definition that they relied on. That requires removing a few uses
> >> outside list.h as well.
> >> 
> >> checkpatch warns about some whitespace issues in list.h, but as I've
> >> copied whole kerneldoc+#define blocks directly from the linux kernel,
> >> I think it's better to just accept that so that we don't introduce
> >> needless diffs. The "macro argument reuse" arguments should also be
> >> ignored, as e.g. the "member" arguments are obviously always just bare
> >> identifiers, and the "pos" arguments must be assigned to multiple
> >> times.
> >> 
> >> Rasmus Villemoes (4):
> >>   linux/list.h: drop use of prefetch()
> >>   treewide: drop no-op prefetch() calls
> >>   mips: drop unused prefetch code and logic
> >>   linux/list.h: drop fallback definition of prefetch()
> >> 
> >>  arch/mips/include/asm/processor.h |  16 -----
> >>  drivers/net/mvpp2.c               |   1 -
> >>  drivers/net/octeontx/nicvf_main.c |   2 -
> >>  drivers/usb/gadget/at91_udc.c     |   1 -
> >>  drivers/usb/musb-new/musb_core.c  |   2 -
> >>  include/linux/list.h              | 104 +++++++++++++++++-------------
> >>  6 files changed, 59 insertions(+), 67 deletions(-)
> >
> > Unfortunately this leads to build problems on lots of platforms:
> > https://source.denx.de/u-boot/u-boot/-/jobs/1141951
> 
> :( 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250525/67d64d1c/attachment.sig>