> -----Original Message----- > From: Andre Vieira (lists) <andre.simoesdiasvie...@arm.com> > Sent: Monday, November 14, 2022 2:09 PM > To: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw <richard.earns...@arm.com>; Richard Sandiford > <richard.sandif...@arm.com> > Subject: Re: [PATCH 1/2] aarch64: Enable the use of LDAPR for load-acquire > semantics > > Here is the latest version and an updated ChangeLog: > > 2022-11-14 Andre Vieira <andre.simoesdiasvie...@arm.com> > Kyrylo Tkachov <kyrylo.tkac...@arm.com> > > gcc/ChangeLog: > > * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): New Macro. > (TARGET_RCPC): New Macro. > * config/aarch64/atomics.md (atomic_load<mode>): Change into an > expand. > (aarch64_atomic_load<mode>_rcpc): New define_insn for ldapr. > (aarch64_atomic_load<mode>): Rename of old define_insn for ldar. > * config/aarch64/iterators.md (UNSPEC_LDAP): New unspec enum > value. > * doc/invoke.texi (rcpc): Ammend documentation to mention the > effects > on code generation. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/ldapr.c: New test.
I don't see this test in the patch? Thanks, Kyrill > > On 10/11/2022 15:55, Kyrylo Tkachov wrote: > > Hi Andre, > > > >> -----Original Message----- > >> From: Andre Vieira (lists) <andre.simoesdiasvie...@arm.com> > >> Sent: Thursday, November 10, 2022 11:17 AM > >> To: gcc-patches@gcc.gnu.org > >> Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Richard Earnshaw > >> <richard.earns...@arm.com>; Richard Sandiford > >> <richard.sandif...@arm.com> > >> Subject: [PATCH 1/2] aarch64: Enable the use of LDAPR for load-acquire > >> semantics > >> > >> Hello, > >> > >> This patch enables the use of LDAPR for load-acquire semantics. After > >> some internal investigation based on the work published by Podkopaev et > >> al. (https://dl.acm.org/doi/10.1145/3290382) we can confirm that using > >> LDAPR for the C++ load-acquire semantics is a correct relaxation. > >> > >> Bootstrapped and regression tested on aarch64-none-linux-gnu. > >> > >> OK for trunk? > > Thanks for the patch > > > >> 2022-11-09 Andre Vieira <andre.simoesdiasvie...@arm.com> > >> Kyrylo Tkachov <kyrylo.tkac...@arm.com> > >> > >> gcc/ChangeLog: > >> > >> * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): New Macro. > >> (TARGET_RCPC): New Macro. > >> * config/aarch64/atomics.md (atomic_load<mode>): Change into > >> an expand. > >> (aarch64_atomic_load<mode>_rcpc): New define_insn for ldapr. > >> (aarch64_atomic_load<mode>): Rename of old define_insn for ldar. > >> * config/aarch64/iterators.md (UNSPEC_LDAP): New unspec enum > >> value. > >> * > >> doc/gcc/gcc-command-options/machine-dependent-options/aarch64- > >> options.rst > >> (rcpc): Ammend documentation to mention the effects on code > >> generation. > >> > >> gcc/testsuite/ChangeLog: > >> > >> * gcc.target/aarch64/ldapr.c: New test. > >> * lib/target-supports.exp (add_options_for_aarch64_rcpc): New > >> options procedure. > >> (check_effective_target_aarch64_rcpc_ok_nocache): New > >> check-effective-target. > >> (check_effective_target_aarch64_rcpc_ok): Likewise. > > diff --git a/gcc/config/aarch64/atomics.md > b/gcc/config/aarch64/atomics.md > > index > bc95f6d9d15f190a3e33704b4def2860d5f339bd..801a62bf2ba432f35ae1931b > eb8c4405b77b36c3 100644 > > --- a/gcc/config/aarch64/atomics.md > > +++ b/gcc/config/aarch64/atomics.md > > @@ -657,7 +657,42 @@ > > } > > ) > > > > -(define_insn "atomic_load<mode>" > > +(define_expand "atomic_load<mode>" > > + [(match_operand:ALLI 0 "register_operand" "=r") > > + (match_operand:ALLI 1 "aarch64_sync_memory_operand" "Q") > > + (match_operand:SI 2 "const_int_operand")] > > + "" > > + { > > + /* If TARGET_RCPC and this is an ACQUIRE load, then expand to a > pattern > > + using UNSPECV_LDAP. */ > > + enum memmodel model = memmodel_from_int (INTVAL > (operands[2])); > > + if (TARGET_RCPC > > + && (is_mm_acquire (model) > > + || is_mm_acq_rel (model))) > > + { > > + emit_insn (gen_aarch64_atomic_load<mode>_rcpc (operands[0], > operands[1], > > + operands[2])); > > + } > > + else > > + { > > + emit_insn (gen_aarch64_atomic_load<mode> (operands[0], > operands[1], > > + operands[2])); > > + } > > > > No braces needed for single-statement bodies. > > > > diff --git a/gcc/doc/gcc/gcc-command-options/machine-dependent- > options/aarch64-options.rst b/gcc/doc/gcc/gcc-command-options/machine- > dependent-options/aarch64-options.rst > > index > c2b23a6ee97ef2b7c74119f22c1d3e3d85385f4d..25d609238db7d45845dbc44 > 6ac21d12dddcf8eac 100644 > > --- a/gcc/doc/gcc/gcc-command-options/machine-dependent- > options/aarch64-options.rst > > +++ b/gcc/doc/gcc/gcc-command-options/machine-dependent- > options/aarch64-options.rst > > @@ -437,9 +437,9 @@ the following and their inverses no > :samp:`{feature}` : > > floating-point instructions. This option is enabled by default for > > :option:`- > march=armv8.4-a`. Use of this option with architectures prior to Armv8.2-A is > not supported. > > > > :samp:`rcpc` > > - Enable the RcPc extension. This does not change code generation from > GCC, > > - but is passed on to the assembler, enabling inline asm statements to use > > - instructions from the RcPc extension. > > + Enable the RcPc extension. This enables the use of the LDAPR > instructions for > > + load-acquire atomic semantics, and passes it on to the assembler, > enabling > > + inline asm statements to use instructions from the RcPc extension. > > > > Let's capitalize this consistently throughout the patch as "RCpc". > > > > diff --git a/gcc/testsuite/gcc.target/aarch64/ldapr.c > b/gcc/testsuite/gcc.target/aarch64/ldapr.c > > new file mode 100644 > > index > 0000000000000000000000000000000000000000..c36edfcd79a9ee41434ab09 > ac47d257a692a8606 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/aarch64/ldapr.c > > @@ -0,0 +1,35 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O1 -std=c99" } */ > > +/* { dg-require-effective-target aarch64_rcpc_ok } */ > > +/* { dg-add-options aarch64_rcpc } */ > > > > If you're not doing an assemble here you probably don't care much about > this target business? (it's more important on the arm side with incompatible > ABIs, Thumb-ness). > > I think in this case you can avoid introducing the effective targets and > > just > add > > #pragma GCC target "+rcpc" > > to the body of the testcase (we use it in a few testcases for aarch64) > > > > Otherwise looks good! > > Thanks, > > Kyrill > >
