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 r12-5998] aarch64: Don't classify vector pairs as short vectors [PR103094] Date: Wed, 15 Dec 2021 12:19:09 +0000 (GMT) [thread overview] Message-ID: <20211215121909.E74E23858D28@sourceware.org> (raw) https://gcc.gnu.org/g:73c3dacef9a30d7d66918606a97c496c71289f1b commit r12-5998-g73c3dacef9a30d7d66918606a97c496c71289f1b Author: Richard Sandiford <richard.sandiford@arm.com> Date: Wed Dec 15 12:19:00 2021 +0000 aarch64: Don't classify vector pairs as short vectors [PR103094] In this PR we were wrongly classifying a pair of 8-byte vectors as a 16-byte “short vector” (in the AAPCS64 sense). As the comment in the patch says, this stems from an old condition in aarch64_short_vector_p that is too loose, but that would be difficult to tighten now. We can still do the right thing for the newly-added modes though, since there are no backwards compatibility concerns there. Co-authored-by: Tamar Christina <tamar.christina@arm.com> gcc/ PR target/103094 * config/aarch64/aarch64.c (aarch64_short_vector_p): Return false for structure modes, rather than ignoring the type in that case. gcc/testsuite/ PR target/103094 * gcc.target/aarch64/pr103094.c: New test. Diff: --- gcc/config/aarch64/aarch64.c | 19 +++++++++++++++++-- gcc/testsuite/gcc.target/aarch64/pr103094.c | 22 ++++++++++++++++++++++ 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index f07330cff4f..ff4a808629b 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -19299,7 +19299,21 @@ aarch64_short_vector_p (const_tree type, else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT) { - /* Rely only on the type, not the mode, when processing SVE types. */ + /* The containing "else if" is too loose: it means that we look at TYPE + if the type is a vector type (good), but that we otherwise ignore TYPE + and look only at the mode. This is wrong because the type describes + the language-level information whereas the mode is purely an internal + GCC concept. We can therefore reach here for types that are not + vectors in the AAPCS64 sense. + + We can't "fix" that for the traditional Advanced SIMD vector modes + without breaking backwards compatibility. However, there's no such + baggage for the structure modes, which were introduced in GCC 12. */ + if (aarch64_advsimd_struct_mode_p (mode)) + return false; + + /* For similar reasons, rely only on the type, not the mode, when + processing SVE types. */ if (type && aarch64_some_values_include_pst_objects_p (type)) /* Leave later code to report an error if SVE is disabled. */ gcc_assert (!TARGET_SVE || aarch64_sve_mode_p (mode)); @@ -19310,7 +19324,8 @@ aarch64_short_vector_p (const_tree type, { /* 64-bit and 128-bit vectors should only acquire an SVE mode if they are being treated as scalable AAPCS64 types. */ - gcc_assert (!aarch64_sve_mode_p (mode)); + gcc_assert (!aarch64_sve_mode_p (mode) + && !aarch64_advsimd_struct_mode_p (mode)); return true; } return false; diff --git a/gcc/testsuite/gcc.target/aarch64/pr103094.c b/gcc/testsuite/gcc.target/aarch64/pr103094.c new file mode 100644 index 00000000000..beda99dc1f6 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/pr103094.c @@ -0,0 +1,22 @@ +/* { dg-do compile } */ +/* { dg-additional-options "-fdump-rtl-expand -w" } */ + +#include <arm_neon.h> + +void foo (uint8x8x2_t cols_01_23, uint8x8x2_t cols_45_67, uint16_t* +outptr0) { + uint16x4x4_t cols_01_23_45_67 = { { + vreinterpret_u16_u8(cols_01_23.val[0]), + vreinterpret_u16_u8(cols_01_23.val[1]), + vreinterpret_u16_u8(cols_45_67.val[0]), + vreinterpret_u16_u8(cols_45_67.val[1]) + } }; + + vst4_lane_u16(outptr0, cols_01_23_45_67, 0); } + +/* Check that we expand to v0 and v2 from the function arguments. */ +/* { dg-final { scan-rtl-dump {\(reg:V2x8QI \d+ v0 \[ cols_01_23 +\]\)} expand } } */ +/* { dg-final { scan-rtl-dump {\(reg:V2x8QI \d+ v2 \[ cols_45_67 +\]\)} expand } } */ +
reply other threads:[~2021-12-15 12:19 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=20211215121909.E74E23858D28@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).