https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #6 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #5) > On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 > > > > --- Comment #4 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- > > Just to be sure I understand: is the PR simply about making the RTL > > representation of the memory more correct? Or is it about generating > > different > > code? > > I'm not sure - it depends on the alignment of VNx4SI(?), if it is > 4 bytes then the RTL wrongly specifies 128bit alignment. If it is > 128bit then the generated GIMPLE from the vectorizer is wrong > (but not exactly sure why). > > The question is really where we make things wrong from which > information. We're producing the code that I'd expect. VNx4SI does have 128-bit alignment, but that's for the sake of LDR and STR. LD1W and ST1W operate on individual 32-bit elements for alignment purposes. So yeah, the 128-bit alignment on the MEM is clearly wrong from a representational perspective, but I wasn't sure whether changing that to 32 was enough to resolve the PR.
