public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-9098] aarch64: Stack-clash prologues and VG saves [PR113995] Date: Wed, 21 Feb 2024 11:12:57 +0000 (GMT) [thread overview] Message-ID: <20240221111258.0A3323858C24@sourceware.org> (raw) https://gcc.gnu.org/g:ad4df8cd080c9be738f61b5e91cc70a594c4419d commit r14-9098-gad4df8cd080c9be738f61b5e91cc70a594c4419d Author: Richard Sandiford <richard.sandiford@arm.com> Date: Wed Feb 21 11:12:27 2024 +0000 aarch64: Stack-clash prologues and VG saves [PR113995] This patch fixes an ICE for a combination of: - -fstack-clash-protection - a frame that has SVE save slots - a frame that has no GPR save slots - a frame that has a VG save slot The allocation code was folding the SVE save slot allocation into the initial frame allocation, so that we had one allocation of size <size of SVE registers> + 16. But the VG save code itself expected the allocations to remain separate, since it wants to store at a constant offset from SP or FP. The VG save isn't shrink-wrapped and so acts as a probe of the initial allocations. It should therefore be safe to keep separate allocations in this case. The scans in locally_streaming_1.c expect no stack clash protection, so the patch forces that and adds a separate compile-only test for when protection is enabled. gcc/ PR target/113995 * config/aarch64/aarch64.cc (aarch64_expand_prologue): Don't fold the SVE allocation into the initial allocation if the initial allocation includes a VG save. gcc/testsuite/ PR target/113995 * gcc.target/aarch64/sme/locally_streaming_1.c: Require -fno-stack-clash-protection. * gcc.target/aarch64/sme/locally_streaming_1_scp.c: New test. Diff: --- gcc/config/aarch64/aarch64.cc | 9 +++++++-- gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1.c | 2 +- gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1_scp.c | 3 +++ 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 104f7e1831ef..6a39ed8eddf7 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -9523,7 +9523,9 @@ aarch64_expand_prologue (void) if (aarch64_cfun_enables_pstate_sm ()) force_isa_mode = AARCH64_FL_SM_ON; - if (flag_stack_clash_protection && known_eq (callee_adjust, 0)) + if (flag_stack_clash_protection + && known_eq (callee_adjust, 0) + && known_lt (frame.reg_offset[VG_REGNUM], 0)) { /* Fold the SVE allocation into the initial allocation. We don't do this in aarch64_layout_arg to avoid pessimizing @@ -9651,7 +9653,10 @@ aarch64_expand_prologue (void) if (maybe_ne (sve_callee_adjust, 0)) { gcc_assert (!flag_stack_clash_protection - || known_eq (initial_adjust, 0)); + || known_eq (initial_adjust, 0) + /* The VG save isn't shrink-wrapped and so serves as + a probe of the initial allocation. */ + || known_eq (frame.reg_offset[VG_REGNUM], bytes_below_sp)); aarch64_allocate_and_probe_stack_space (tmp1_rtx, tmp0_rtx, sve_callee_adjust, force_isa_mode, diff --git a/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1.c b/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1.c index 4bb637f4781d..cb235f5c832d 100644 --- a/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1.c +++ b/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1.c @@ -1,4 +1,4 @@ -// { dg-options "-O -fomit-frame-pointer" } +// { dg-options "-O -fomit-frame-pointer -fno-stack-clash-protection" } // { dg-final { check-function-bodies "**" "" } } void consume_za () [[arm::streaming, arm::inout("za")]]; diff --git a/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1_scp.c b/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1_scp.c new file mode 100644 index 000000000000..6b7f47dce7aa --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/sme/locally_streaming_1_scp.c @@ -0,0 +1,3 @@ +// { dg-options "-O -fomit-frame-pointer -fstack-clash-protection" } + +#include "locally_streaming_1.c"
reply other threads:[~2024-02-21 11:12 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240221111258.0A3323858C24@sourceware.org \ --to=rsandifo@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).