[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5afnvgygh3nk34oqiaq7cj5mqbbnz2vaokpsz2mmv6kqo76bd@4744h2x4zsvm>
Date: Mon, 19 Feb 2024 05:08:47 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Arnd Bergmann <arnd@...db.de>
Cc: Russell King <linux@...linux.org.uk>,
Calvin Owens <jcalvinowens@...il.com>, Dave Martin <Dave.Martin@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
"linux-bcachefs@...r.kernel.org" <linux-bcachefs@...r.kernel.org>
Subject: Re: [PATCH] arm: Silence gcc warnings about arch ABI drift
On Mon, Feb 19, 2024 at 10:57:46AM +0100, Arnd Bergmann wrote:
> On Mon, Feb 19, 2024, at 10:40, Kent Overstreet wrote:
> > On Mon, Feb 19, 2024 at 09:26:51AM +0000, Russell King (Oracle) wrote:
> >> On Mon, Feb 19, 2024 at 07:21:11AM +0100, Arnd Bergmann wrote:
> >>
> >> +1 - bcachefs definitely needs fixing. Passing all that as an argument
> >> not only means that it has to be read into registers, but also when
> >> accessing members, it has to be extracted from those registers as well.
> >>
> >> Passing that by argument is utterly insane.
> >
> > If the compiler people can't figure out a vaguely efficient way to pass
> > a small struct by value, that's their problem - from the way you
> > describe it, I have to wonder at what insanity is going on there.
>
> On most ABIs, there are only six argument registers (24 bytes)
> for function calls. The compiler has very little choice here if
> it tries to pass 32 bytes worth of data.
>
> On both x86_64 and arm64, there are theoretically enough
> registers to pass the data, but kernel disallows using the
> vector and floating point registers for passing large
> compounds arguments.
>
> The integer registers on x86 apparently allow passing compounds
> up to 16 bytes, but only if all members are naturally aligned.
> Since you have both __packed members and bitfields, the compiler
> would not even be allowed to pass the structure efficiently
> even if it was small enough.
from an efficiency pov, the thing that matters is whether the
compiler is going to emit a call to memcpy (bad) or inline the copy -
and also whether the compiler can elide the copy if the variable is
never modified in the callee.
if were passing by reference it's also going to be living on the stack,
not registers.
Powered by blists - more mailing lists