[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- The pre-checkin CI suggests this should be resolved fully.
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:175b49933ffeea6d4a690e40bba006854977f43f commit r16-2333-g175b49933ffeea6d4a690e40bba006854977f43f Author: Richard Biener Date: Thu Jul 17 08:51:11 2025 +0200 tree-optimization/121048 - move check for only having vector(1) The following moves rejecting loop vectorization with vector(1) typed vectors from the initial vector type determining to after SLP discovery when we can check whether there's any instance with other than vector(1) vectors. For RVV at least vector(1) instances serve as a limited way to support partial loop vectorization. The following restores this. PR tree-optimization/121048 * tree-vect-loop.cc (vect_determine_vectype_for_stmt_1): Remove rejecting vector(1) vector types. (vect_set_stmts_vectype): Likewise. * tree-vect-slp.cc (vect_make_slp_decision): Only count instances with non-vector(1) root towards whether we have any interesting instances to vectorize.
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- Mine.
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2025-07-14
Status|UNCONFIRMED |NEW
--- Comment #3 from Richard Biener ---
(In reply to Robin Dapp from comment #2)
> Those zve32 tests often do single-element vectorization.
>
> In zve32f-1.c we don't vectorize
>
> void
> foo1 (int16_t *__restrict f, int32_t *__restrict d, int n)
> {
> for (int i = 0; i < n; ++i)
> {
> f[i * 2 + 0] = 1;
> f[i * 2 + 1] = 2;
> d[i] = 3;
> }
> }
>
> any more due to
>
> if (known_le (TYPE_VECTOR_SUBPARTS (stmt_vectype), 1U))
> return opt_result::failure_at (STMT_VINFO_STMT (stmt_info),
> "not vectorized: unsupported "
> "data-type in %G",
> STMT_VINFO_STMT (stmt_info));
>
> where we give up on the single-element store (but the load has two elements).
>
> Without having had a closer look, would we not only want to fail when all
> statements have known_le (..., 1U) rather than just one?
I guess yes, this then depends on "partial vectorization" being done via
having vector(1) for all stmts not vectorizable. Note there isn't a
convenient place to assess this when only doing SLP. But I'll think
of one. Note there is the opposite testsuite coverage to verify we
are not vectorizing a loop with only vector(1) types.
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
Those zve32 tests often do single-element vectorization.
In zve32f-1.c we don't vectorize
void
foo1 (int16_t *__restrict f, int32_t *__restrict d, int n)
{
for (int i = 0; i < n; ++i)
{
f[i * 2 + 0] = 1;
f[i * 2 + 1] = 2;
d[i] = 3;
}
}
any more due to
if (known_le (TYPE_VECTOR_SUBPARTS (stmt_vectype), 1U))
return opt_result::failure_at (STMT_VINFO_STMT (stmt_info),
"not vectorized: unsupported "
"data-type in %G",
STMT_VINFO_STMT (stmt_info));
where we give up on the single-element store (but the load has two elements).
Without having had a closer look, would we not only want to fail when all
statements have known_le (..., 1U) rather than just one?
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 Richard Biener changed: What|Removed |Added Target||riscv Target Milestone|--- |16.0 Keywords||testsuite-fail Component|tree-optimization |target Version|unknown |16.0 --- Comment #1 from Richard Biener --- This wasn't really expected - on the aarch64 side there was fallout with using the VF in costing in the scalar side. So, it needs to be investigated why this happens, I suspect a similar reason on the costing side in the backend.
