https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127407
Bug ID: 127407
Summary: [14/15/16/17 Regression] wrong code with store group
and negative dependence distance since
r6-4137-g90a7a1b5b2c551
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: konstantinos.eleftheriou at vrull dot eu
CC: rguenther at suse dot de
Target Milestone: ---
Target: aarch64-linux-gnu
Created attachment 65598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65598&action=edit
testcase
The attached reduced_testcase.c generates wrong code at -O3 on AArch64:
$ gcc -O3 reduced_testcase.c && ./a.out
Aborted
$ gcc -O3 -fno-tree-vectorize reduced_testcase.c && ./a.out # OK
It fails with GCC 6 to 9 and with GCC 14 up to current trunk. GCC 10 to 13
consider the loop not profitable and only fail with -fno-vect-cost-model.
GCC 5 doesn't vectorize the loop. Started with r6-4137-g90a7a1b5b2c551, which
vectorizes px[-2] as a strided access instead of rejecting the loop.
px[-2] in iteration i+1 writes the element that px[0] wrote in iteration i, so
a[2*k] should end up as k + 100. The vectorizer groups the stores to px[0] and
px[1] and emits the group at px[1], after the store to px[-2], so within each
vector iteration the value from the earlier iteration wins. On aarch64
a[2], a[4], ..., a[16] come out as 0, 1, 2, 104, 4, 5, 6, 108 instead of
101, ..., 108.
vect_analyze_data_ref_dependence checks vect_preserves_scalar_order_p for
dist == 0, but the dist > 0 && DDR_REVERSED_P case just continues, so this
reordering of two writes is never caught. This case goes back to
r0-83300-gf5d8ed2c51c746, which started treating negative distances as no
dependence. Store groups were already emitted at their last store back then,
so the check has been missing since. r6-4137-g90a7a1b5b2c551 just made
loops like this one reach it.
