Re: [PATCH] riscv/atomic: Do proper sign extension also for unsigned in arch_cmpxchg

[Jessica Clarke <jrtc27@jrtc27.com>]

On 3 Feb 2025, at 13:57, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> 
> On Thu, 30 Jan 2025, Jessica Clarke wrote:
> 
>>>> a2 is used as it is passed by the calling function, so we can't be sure a2
>>>> is sign extended to me, what am I missing?
>>> 
>>> 32-bit scalar arguments are guaranteed to be sign extended on entry.
>> 
>> Firstly, the calling convention is irrelevant if the function is
>> inlined, which this almost always will be.
> 
> Umm, that would be a compiler bug then, as inlining is supposed not to 
> change language semantics.  IOW the compiler is expected to explicitly 
> sign-extend the arguments of an inlined function at their evaluation point 
> just as it would at an actual function call unless the compiler is able to 
> prove they have come out sign-extended already from previous operations.

No it’s not. The calling convention is there so that each side of the
call know how the data is being passed between them. When inlining
occurs there is no such call and compilers can do whatever they like.
Calling conventions say absolutely nothing about what the
representation of a value is whilst inside a function, only at
boundaries. The ABI can also tell you what the observable
representation of values within a function should be (e.g. that int is
a 32-bit two’s complement value), but just like other platforms there
is nothing in the RISC-V ABI specifications to say that 32-bit integers
are kept sign-extended in registers, and that’s not going to be added
because LLVM has never implemented that for RISC-V so it would be an
ABI break for all LLVM-compiled RV64 code in existence.

Jess