https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127049
--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
Claude's analysis of -fdump-tree-vect-details-blocks dump:
The actual smoking gun is vect_analyze_data_refs_alignment, around line 179:
recording new base alignment for (struct element_type &) _49 + (((sizetype)
node_idx_553 - (sizetype) _581) * 128 + (sizetype) size_582) * 4
alignment: 64
misalignment: 0
That's the outer-loop-vectorized base address for the store, and it bakes
size_582 — an unconstrained SSA value with no known low bits — directly into
the additive term, then reports misalignment: 0 for the whole thing. There's
nothing that could justify that; the only thing known about size_582*4 is that
it's a multiple of 4, which caps provable alignment at 4 bytes, not 16. That
bogus misalignment: 0 propagates straight through
vect_compute_data_ref_alignment ("missed: misalign = 0 bytes of ref...") into
vect_model_store_cost: aligned. at line 195 — no alignment peeling, no runtime
check, straight to movaps.
Best part: you don't even need to argue this from first principles. The same
file has a control case a few thousand lines down (prXX.C:67:36, the
point-initialization loop in main) with an analogous unconstrained start value,
and there the ordinary (non-outer) loop vectorizer gets it right — "Unknown
misalignment, naturally aligned" → "Vectorizing an unaligned access." So the
defect is specifically in how the outer-loop-vectorization base-alignment path
composes an unconstrained IV-start term into its base address, not in the
general DR-alignment machinery, which is demonstrably correct one loop over.
That also tracks with -fno-tree-loop-vectorize fixing it while
-fno-tree-slp-vectorize doesn't: outer-loop vectorization is a
loop-vectorizer-only feature, orthogonal to SLP.
