Re: [PATCH V2] RISC-V: Add support for Zalasr extension

/amo/zalasr-ztso-store-compat-seq-cst.c: New test. > * gcc.target/riscv/amo/zalasr-ztso-store-relaxed.c: New test. > * gcc.target/riscv/amo/zalasr-ztso-store-release.c: New test. > > Signed-off-by: Edwin Lu > --- > v2: fix ztso mappings > - Removed .aq annotation on load acquire > - Removed .rl annotation on store release LGTM, Reviewed-by: Andrea Parri Andrea

Re: [PATCH] RISC-V: Add support for Zalasr extension

> @@ -54,8 +54,13 @@ (define_insn "atomic_load_ztso" > if (model == MEMMODEL_SEQ_CST) >return "fence\trw,rw\;" >"\t%0,%1"; > -else > - return "\t%0,%1"; > + > +/* Ignoring RCsc atomic load-acquire on MEMMODEL_SEQ_CST due to > + Note 3 abi break. */ > +

Re: [PATCH v2] RISC-V: Add basic support for the Zacas extension

e.c: > New test. > * > gcc.target/riscv/amo/zacas-ztso-compare-exchange-compatability-mapping.cc: > New test. > * gcc.target/riscv/amo/zacas-ztso-compare-exchange-int-seq-cst.c: New > test. > * gcc.target/riscv/amo/zacas-ztso-compare-exchange-int.c: New test. > * gcc.target/riscv/amo/zacas-ztso-compare-exchange-short-seq-cst.c: New > test. > * gcc.target/riscv/amo/zacas-ztso-compare-exchange-short.c: New test. > > Co-authored-by: Patrick O'Neill LGTM; feel free to add: Tested-by: Andrea Parri Andrea

Re: [PATCH] RISC-V: Add support for Zabha extension

> I think your interpretation of "depends on" is reasonable, but it's not the > way we've handled it for other extension dependencies. For the others we're > treating "depends on" the way this code does, ie enabling the dependant > extensions implicitly. IIRC that's how the RISC-V specs want it t

Re: [PATCH] RISC-V: Add support for Zabha extension

is intentional - my understanding is that GCC adds extensions if the > specified extensions depend upon them. Thanks for the clarification. For the patch at stake, Tested-by: Andrea Parri Andrea

Re: [PATCH] RISC-V: Add support for Zabha extension

> Tested using amo.exp with rv64gc_zalrsc, rv64id_zaamo, rv64id_zalrsc, > rv64id_zabha (using tip-of-tree qemu w/ zabha patches [2] applied for > execution tests). My interpretation of the Zabha specification, in particular of "The Zabha extension depends upon the Zaamo standard extension", is tha

Re: [PATCH] RISC-V: Add support for subword atomic loads/stores

On Wed, Jun 12, 2024 at 05:10:13PM -0700, Patrick O'Neill wrote: > Andrea Parri recently pointed out that we were emitting overly conservative > fences for seq_cst atomic loads/stores. This adds support for the optimized > fences specified in the PSABI: > https://github.com/riscv-

Re: [PATCH v3 0/3] RISC-V: Add basic Zaamo and Zalrsc support

s While providing a proper/detailed review of the series goes above my "GCC internals" skills, I've applied the series and checked that the generated code for some atomic operations meet expectations (expecta- tions which, w/ "only Zaamo", are arguably quite low as mention

Re: [RFC] RISC-V: Add proposed Ztso atomic mappings

On Fri, May 05, 2023 at 02:42:38PM -0700, Hans Boehm wrote: > I think A.6-tso also needs to change the last line in the table from > lr.aqrl ... sc to lr.aq ... sc.rl, otherwise I think we have problems with > a subsequent A.7-tso generated l.aq . Otherwise I agree. Indeed! Thanks for the correct

Re: [RFC] RISC-V: Add proposed Ztso atomic mappings

On Fri, May 05, 2023 at 12:18:12PM -0700, Palmer Dabbelt wrote: > On Fri, 05 May 2023 11:55:31 PDT (-0700), Andrea Parri wrote: > > On Fri, May 05, 2023 at 10:12:56AM -0700, Patrick O'Neill wrote: > > > The RISC-V Ztso extension currently has no effect on generated code. &g

Re: [RFC] RISC-V: Add proposed Ztso atomic mappings

On Fri, May 05, 2023 at 10:12:56AM -0700, Patrick O'Neill wrote: > The RISC-V Ztso extension currently has no effect on generated code. > With the additional ordering constraints guarenteed by Ztso, we can emit > more optimized atomic mappings than the RVWMO mappings. > > This patch implements And

Re: [PATCH v5 00/11] RISC-V: Implement ISA Manual Table A.6 Mappings

pings were different, > but it wasn't clear if these unique mappings had correctness issues. > > Andrea Parri found an issue with the GCC mappings, showing that > atomic_compare_exchange_weak_explicit(-,-,-,release,relaxed) mappings do > not enforce release ordering guarantees. (

Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]

On Wed, Oct 12, 2022 at 07:16:20PM +0200, Andrea Parri wrote: > > > > +Andrea, in case he has time to look at the memory model / ABI > > > > issues. > > > +Jeff, who was offering to help when the threads got crossed. I'd punted on > > a lot o

Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]

> > > +Andrea, in case he has time to look at the memory model / ABI > > > issues. > +Jeff, who was offering to help when the threads got crossed. I'd punted on > a lot of this in the hope Andrea could help out, as I'm not really a memory > model guy and this is pretty far down the rabbit