Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is not true on SPARCv8 processors

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR port-sparc/57515; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is
	not true on SPARCv8 processors
Date: Sat, 8 Jul 2023 21:40:46 +0000

 > Date: Sat, 8 Jul 2023 23:24:50 +0200
 > From: Martin Husemann <martin%duskware.de@localhost>
 >=20
 > On Sat, Jul 08, 2023 at 08:19:37PM +0000, Taylor R Campbell wrote:
 > > If a `NetBSD/sparc' userland is supposed to work on sparcv7 and
 > > sparcv8 CPUs, well, that's a problem, because these are both broken:
 >=20
 > Well, I don't know about v8 and early details, but kinda assumed it
 > would be similar to v9 where it is under (kernel's) software controll
 > (and binaries get run with the memory model they are compiled for).
 
 Ah -- it is possible that the v7-targeted compiler will generate
 binaries with memory model SC instead of TSO, in which case there's no
 bug here, but there is a substantial performance impact on MP sparcv8
 by forcing SC for everything.
 
 (There's also a performance impact on sparcv8 by forcing out-of-line
 multiplication -- but if I recall correctly we have libc substitute on
 sparcv8 via ld.so.conf that uses the CPU instructions, at least,
 instead of software multiplication.)
 
 > If that is not the case we should make v8 the default, adjust documentati=
 on
 > and provide support for v7 as source only. Few machines are left over
 > in working condition.
 
 That's an option too, but I bet it could be made to work reasonably
 well with a small tweak to gcc so that NetBSD can ask for -mcpu=3Dv7
 -mmemory-model=3Dtso instead of having -mcpu=3Dv7 ignore -mmemory-model,
 if someone is willing to do the work and testing for it.