https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127467
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
CC| |ptomsich at gcc dot gnu.org
Last reconfirmed| |2026-09-18
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I see
> ./cc1 -quiet t.c -O3 -march=x86-64-v4 -mtune-ctrl=avx512_avoid_vec_perm
> -fopt-info-vec -mprefer-vector-width=512
t.c:10:25: optimized: loop vectorized using 32 byte vectors and unroll factor 1
t.c:14:52: optimized: basic block part vectorized using 32 byte vectors
so it works? With -mprefer-width=256 I see
t.c:10:25: optimized: loop vectorized using 32 byte vectors and unroll factor 1
t.c:19:28: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:1:6: optimized: basic block part vectorized using 32 byte vectors
t.c:14:52: optimized: basic block part vectorized using 32 byte vectors
so the difference is somehow in BB vectorization only, and this might be
because with BB vectorization once _any_ SLP subgraph is profitable with
a selected mode (so 256 vs 512) we do _not_ attempt to re-vectorize with
another mode. Mostly because the iteration is somewhat pointless - SLP
discovery would not be different, we chose vector types based on the
SLP layout and not strictly adhere to the mode.
But sure, taking a not profitable SLP subgraph and simply re-assigning
vector types would be a more proper implementation of mode iteration.
I think I've seen folks working on something like that?
