https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2025-07-14
Status|UNCONFIRMED |NEW
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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.
