procyberian/gcc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

aarch64: Don't classify vector pairs as short vectors [PR103094]

Browse source 
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.
This commit is contained in:
Richard Sandiford 2021-12-15 12:19:00 +00:00
parent 7527ddecef
commit 73c3dacef9
2 changed files with 39 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
gcc/config/aarch64/aarch64.c
View file

@ -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;

22
gcc/testsuite/gcc.target/aarch64/pr103094.c Normal file
View file

@ -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 } } */