RFR: 8316186: RISC-V: Remove PlatformCmpxchg<4>

[Robbin Ehn]

On Wed, 13 Sep 2023 12:25:41 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> I don't know the history behind the Cmpxhg<4>, but it is not needed anymore.
> Using compiler as in 8 byte case is just fine.
> 
> Passes hotspot-tier (qemu, vf2 still running), some manual extra testing via gtest, looked at compiler: output, e.g. https://godbolt.org/z/a31Gdqn8q
> 
> If you know the history please share, and if you have a reason why we should keep it please speak up!

I asked around, there is no known bug.
And if there was a bug it can't be the " __atomic_compare_exchange" it self I was told.
"As per ABI, 32-bit quantities in 64-bit container have to be sign-extended"

The compare value is passed as pointer, the normal generate code is:
"lw      a3,0(a5)"
"LW instruction loads a 32-bit value from memory and sign-extends this to 64 bits"

gcc 8.2 seems to generate the same code as gcc 13/tip.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15715#issuecomment-1720714850