Re: [GIT PULL] Add two-byte cmpxchg emulation function for v7.4

[Paul E. McKenney]

On Tue, Nov 03, 2026 at 10:47:25PM +0000, David Laight wrote:
> On Tue, 3 Nov 2026 10:19:23 -0800
> "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> 
> > On Tue, Nov 03, 2026 at 03:03:47AM +0100, Jan Engelhardt wrote:
> > > 
> > > On Monday 2026-11-02 17:34, David Laight wrote:  
> > > >> 
> > > >> I can get gcc-17.0.0-20261102 with no further command line options
> > > >> to turn `atomic_compare_exchange_strong`+uint16 into some object code
> > > >> that does not contain a call to libatomic, for sh2, sh3, sh4. Haven't 
> > > >> tried xtensa or the others.
> > > >> Thus, is the patch really needed?  
> > > >
> > > >Won't that need a big jump in the minimum supported compiler version?  
> > > 
> > > 12.0.0-20210420 behaves the same. I just chose 17 because that was
> > > convenient to try first.  
> > 
> > Are you also advocating ditching the single-byte cmpxchg() emulation?
> > If the compiler really can handle this emulation for all sizes on all
> > supported compilers on all affected architectures, that is actually not
> > at all an unattractive approach.
> 
> What is the 'bloat factor'?
> While the function call costs, the atomic op isn't cheap either.
> Or are you putting the compiler generated code in the function?

Fair points!  Perhaps this choice should be make on a per-architecture
basis, given that different architectures might have different costs for
atomic operations vs. function calls.  In which case, lib/cmpxchg-emu.c
provides the emulation functions for those architectures/systems that
benefit from it.

And if at some future time, no architecture uses these emulation
functions, that would be a good time to start thinking about removing
them.

							Thanx, Paul