Thanks Kyrill! I will be happy to test the gcc-8 back-port of the patches.
We would also need to back-port the patches to gcc-7.
I hope it is ok to commit the changes to the gcc-7 branch even if it is not a
maintained branch.
Sebastian
On 4/1/20, 9:27 AM, "Kyrylo Tkachov" <kyrylo.tkac...@arm.com> wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
Adding gcc-patches as I had somehow deleted it from the addresses...
> -----Original Message-----
> From: Kyrylo Tkachov
> Sent: 01 April 2020 15:23
> To: Pop, Sebastian <s...@amazon.com>
> Cc: Wilco Dijkstra <wilco.dijks...@arm.com>; richard.hender...@linaro.org
> Subject: RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
>
> Hi Sebastian,
>
> > -----Original Message-----
> > From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of Pop,
> > Sebastian via Gcc-patches
> > Sent: 31 March 2020 16:47
> > To: Kyrill Tkachov <kyrylo.tkac...@foss.arm.com>;
> > gcc-patches@gcc.gnu.org
> > Cc: Wilco Dijkstra <wilco.dijks...@arm.com>;
> > richard.hender...@linaro.org
> > Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and
> > 8.x
> >
> > Ping, can we have the -moutline-atomics patches committed to the gcc-9
> > branch?
>
> Thanks for testing the patches.
>
> >
> > Thanks,
> > Sebastian
> >
> > On 3/24/20, 7:24 PM, "Pop, Sebastian" <s...@amazon.com> wrote:
> >
> > Hi Kyrill,
> >
> > Thanks for pointing out the two missing bug fixes.
> > Please see attached all the back-ported patches.
> > All the patches from trunk applied cleanly with no conflicts
> > (except for the ChangeLog files) to the gcc-9 branch.
> > An up to date gcc-9 branch on which I applied the attached patches
> > has passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and
> > make check with no extra fails.
> > Kyrill, could you please commit the attached patches to the gcc-9
branch?
>
> This series also needs Jakub's recent fix:
https://gcc.gnu.org/pipermail/gcc-
> patches/2020-March/542952.html
> I've tested this together with the rest and committed the whole series to
the
> gcc-9 branch.
>
> >
> > As we still don't have a copyright assignment on file, would it be
> > possible for ARM to finish the backport to the gcc-8 branch of these
> > patches and the atomics cleanup patches mentioned below?
>
> I can help with that, but any help with testing the patch set would be
> appreciated.
> Thanks,
> Kyrill
>
> >
> > I did a `git log config/aarch64/atomics.md` and there is a
> > follow-up patch to the atomics cleanup patches:
> >
> > commit e21679a8bb17aac603b8704891e60ac502200629
> > Author: Jakub Jelinek <ja...@redhat.com>
> > Date: Wed Nov 21 17:41:03 2018 +0100
> >
> > re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
> >
> > PR target/87839
> > * config/aarch64/atomics.md
> > (@aarch64_compare_and_swap<mode>): Use
> > rIJ constraint for aarch64_plus_operand rather than rn.
> >
> > * gcc.target/aarch64/pr87839.c: New test.
> >
> > From-SVN: r266346
> >
> > That is fixing code modified in this cleanup patch:
> >
> > commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> > Author: Richard Henderson <richard.hender...@linaro.org>
> > Date: Wed Oct 31 09:42:39 2018 +0000
> >
> > aarch64: Improve cas generation
> >
> >
> > Thanks,
> > Sebastian
> >
> >
> > On 3/11/20, 5:11 AM, "Kyrill Tkachov"
> > <kyrylo.tkac...@foss.arm.com>
> > wrote:
> >
> > CAUTION: This email originated from outside of the
> > organization. Do not click links or open attachments unless you can
> > confirm the sender and know the content is safe.
> >
> >
> >
> > Hi Sebastian,
> >
> > On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > > Hi,
> > >
> > > Please see attached the patches to add -moutline-atomics to
> > the gcc-9 branch.
> > > Tested on graviton2 aarch64-linux with bootstrap and
> > > `make check` passes with no new fails.
> > > Tested `make check` on glibc built with gcc-9 with and
> > without "- moutline-atomics"
> > > and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
> > >
> > > Ok to commit to gcc-9 branch?
> >
> > Since this feature enables backwards-compatible deployment of
LSE
> > atomics, I'd support that.
> >
> > That is okay with me in principle after GCC 9.3 is released
(the branch
> > is currently frozen).
> >
> > However, there have been a few follow-up patches to fix some
bugs
> > revealed by testing.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833
> >
> > and
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834
> >
> > come to mind.
> >
> > Can you please make sure the fixes for those are included as
well?
> >
> >
> > >
> > > Does this mechanical `git am *.patch` require a copyright
assignment?
> > > I am still working with my employer on getting the FSF
> > assignment signed.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > PS: For gcc-8 backports there are 5 cleanup and improvement
> patches
> > > that are needed for -moutline-atomics patches to apply
cleanly.
> > > Should these patches be back-ported in the same time as the
> > flag patches,
> > > or should I update the patches to apply to the older code
base?
> >
> > Hmm... normally I'd be for them. In this case I'd want to make
sure
> that
> > there aren't any fallout fixes that we're missing.
> >
> > Did these patches have any bug reports against them?
> >
> > Thanks,
> >
> > Kyrill
> >
> >
> > > Here is the list of the extra patches:
> > >
> > > From 77f33f44baf24c22848197aa80962c003dd7b3e2 Mon Sep 17
> > 00:00:00 2001
> > > From: Richard Henderson <richard.hender...@linaro.org>
> > > Date: Wed, 31 Oct 2018 09:29:29 +0000
> > > Subject: [PATCH] aarch64: Simplify LSE cas generation
> > >
> > > The cas insn is a single insn, and if expanded properly need
not
> > > be split after reload. Use the proper inputs for the insn.
> > >
> > > * config/aarch64/aarch64.c
> > (aarch64_expand_compare_and_swap):
> > > Force oldval into the rval register for TARGET_LSE;
emit the
> > compare
> > > during initial expansion so that it may be deleted
if unused.
> > > (aarch64_gen_atomic_cas): Remove.
> > > * config/aarch64/atomics.md
> > (@aarch64_compare_and_swap<SHORT>_lse):
> > > Change =&r to +r for operand 0; use match_dup for
operand 2;
> > > remove is_weak and mod_f operands as unused. Drop
the split
> > > and merge with...
> > > (@aarch64_atomic_cas<SHORT>): ... this pattern's
output;
> > remove.
> > > (@aarch64_compare_and_swap<GPI>_lse): Similarly.
> > > (@aarch64_atomic_cas<GPI>): Similarly.
> > >
> > > From-SVN: r265656
> > >
> > > From d400fda3a8c3330f77eb9d51874f5482d3819a9f Mon Sep 17
> > 00:00:00 2001
> > > From: Richard Henderson <richard.hender...@linaro.org>
> > > Date: Wed, 31 Oct 2018 09:42:39 +0000
> > > Subject: [PATCH] aarch64: Improve cas generation
> > >
> > > Do not zero-extend the input to the cas for subword
operations;
> > > instead, use the appropriate zero-extending compare insns.
> > > Correct the predicates and constraints for immediate
> > expected operand.
> > >
> > > * config/aarch64/aarch64.c
> > (aarch64_gen_compare_reg_maybe_ze): New.
> > > (aarch64_split_compare_and_swap): Use it.
> > > (aarch64_expand_compare_and_swap): Likewise. Remove
> > convert_modes;
> > > test oldval against the proper predicate.
> > > * config/aarch64/atomics.md
> > (@atomic_compare_and_swap<ALLI>):
> > > Use nonmemory_operand for expected.
> > > (cas_short_expected_pred): New.
> > > (@aarch64_compare_and_swap<SHORT>): Use it; use "rn"
not
> > "rI" to match.
> > > (@aarch64_compare_and_swap<GPI>): Use "rn" not "rI"
for
> > expected.
> > > * config/aarch64/predicates.md
(aarch64_plushi_immediate):
> > New.
> > > (aarch64_plushi_operand): New.
> > >
> > > From-SVN: r265657
> > >
> > > From 8f5603d363a4e0453d2c38c7103aeb0bdca85c4e Mon Sep 17
> > 00:00:00 2001
> > > From: Richard Henderson <richard.hender...@linaro.org>
> > > Date: Wed, 31 Oct 2018 09:47:21 +0000
> > > Subject: [PATCH] aarch64: Improve swp generation
> > >
> > > Allow zero as an input; fix constraints; avoid unnecessary
split.
> > >
> > > * config/aarch64/aarch64.c
(aarch64_emit_atomic_swap):
> > Remove.
> > > (aarch64_gen_atomic_ldop): Don't call it.
> > > * config/aarch64/atomics.md (atomic_exchange<ALLI>):
> > > Use aarch64_reg_or_zero.
> > > (aarch64_atomic_exchange<ALLI>): Likewise.
> > > (aarch64_atomic_exchange<ALLI>_lse): Remove split;
remove &
> > from
> > > operand 0; use aarch64_reg_or_zero for input; merge
...
> > > (@aarch64_atomic_swp<ALLI>): ... this and remove.
> > >
> > > From-SVN: r265659
> > >
> > > From 7803ec5ee2a547043fb6708a08ddb1361ba91202 Mon Sep 17
> > 00:00:00 2001
> > > From: Richard Henderson <richard.hender...@linaro.org>
> > > Date: Wed, 31 Oct 2018 09:58:48 +0000
> > > Subject: [PATCH] aarch64: Improve atomic-op lse generation
> > >
> > > Fix constraints; avoid unnecessary split. Drop the use of the
> atomic_op
> > > iterator in favor of the ATOMIC_LDOP iterator; this is
> > simplier and more
> > > logical for ldclr aka bic.
> > >
> > > * config/aarch64/aarch64.c (aarch64_emit_bic):
Remove.
> > > (aarch64_atomic_ldop_supported_p): Remove.
> > > (aarch64_gen_atomic_ldop): Remove.
> > > * config/aarch64/atomic.md
(atomic_<atomic_optab><ALLI>):
> > > Fully expand LSE operations here.
> > > (atomic_fetch_<atomic_optab><ALLI>): Likewise.
> > > (atomic_<atomic_optab>_fetch<ALLI>): Likewise.
> > > (aarch64_atomic_<ATOMIC_LDOP><ALLI>_lse): Drop
atomic_op
> > iterator
> > > and use ATOMIC_LDOP instead; use register_operand
for the
> > input;
> > > drop the split and emit insns directly.
> > > (aarch64_atomic_fetch_<ATOMIC_LDOP><ALLI>_lse):
Likewise.
> > > (aarch64_atomic_<atomic_op>_fetch<ALLI>_lse): Remove.
> > > (@aarch64_atomic_load<ATOMIC_LDOP><ALLI>): Remove.
> > >
> > > From-SVN: r265660
> > >
> > > From 53de1ea800db54b47290d578c43892799b66c8dc Mon Sep 17
> > 00:00:00 2001
> > > From: Richard Henderson <richard.hender...@linaro.org>
> > > Date: Wed, 31 Oct 2018 23:11:22 +0000
> > > Subject: [PATCH] aarch64: Remove early clobber from
> > ATOMIC_LDOP scratch
> > >
> > > * config/aarch64/atomics.md
> > (aarch64_atomic_<ATOMIC_LDOP><ALLI>_lse):
> > > The scratch register need not be early-clobber.
Document the
> > reason
> > > why we cannot use ST<OP>.
> > >
> > > From-SVN: r265703
> > >
> > >
> > >
> > >
> > >
> > > On 2/27/20, 12:06 PM, "Kyrill Tkachov"
> > <kyrylo.tkac...@foss.arm.com>
> > wrote:
> > >
> > > Hi Sebastian,
> > >
> > > On 2/27/20 4:53 PM, Pop, Sebastian wrote:
> > > >
> > > > Hi,
> > > >
> > > > is somebody already working on backporting
-moutline-atomics
> to
> > gcc
> > > > 8.x and 9.x branches?
> > > >
> > > I'm not aware of such work going on.
> > >
> > > Thanks,
> > >
> > > Kyrill
> > >
> > > > Thanks,
> > > >
> > > > Sebastian
> > > >
> > >
> > >
> >
> >
> >
