Before r14-2877-gbf67bf4880ce5be0, the aarch64 code assumed that
every multi-vector reduction would use single def-use cycles.
The patch fixed it to test what the vectoriser actually planned
to do, using newly provided information.
At the time, we didn't try to use single def-use cycles for any costed
variant in the associated testcase (gcc.target/aarch64/pr110625_1.c),
so it was enough to check that the single-def-use latency was never
printed to the dump file. However, we do now consider using single
def-use cycles for the single-lane SLP fallback.
This patch therefore switches to a positive test of the
non-single-def-use latency. I checked that the test still failed
in this form before r14-2877-gbf67bf4880ce5be0.
Tested on aarch64-linux-gnu. I'll push tomorrow if there are no
objections.
Richard
gcc/testsuite/
* gcc.target/aarch64/pr110625_1.c: Turn into a positive test for
a vector latency of 2, rather than a negative test for a vector
latency of 8.
---
gcc/testsuite/gcc.target/aarch64/pr110625_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/pr110625_1.c
b/gcc/testsuite/gcc.target/aarch64/pr110625_1.c
index 0965cac33a0..1d0033c9833 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr110625_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr110625_1.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-Ofast -mcpu=neoverse-n2 -fdump-tree-vect-details
-fno-tree-slp-vectorize" } */
-/* { dg-final { scan-tree-dump-not "reduction latency = 8" "vect" } } */
+/* { dg-final { scan-tree-dump {Vector issue estimate:(?:(?!Cost
model).)*reduction latency = 2\n} "vect" } } */
/* Do not increase the vector body cost due to the incorrect reduction latency
Original vector body cost = 51
--
2.25.1
