https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #27 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> >
> > * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> > {r0:SI..r3:SI}
> >
> > isn't considered as dependence? Why does the earlier insn even come into
> > play? What's the breaking transform? I guess insn 119 and 120 are
> > exchanged?
>
> Because 119 was deleted by postreload. Doh! I should have spotted that.
But that ought to be ok, insn 115 is a store in alias set 0, so is picked up by
later alias analysis. It's just that the compiler then digs deeper and decides
that that isn't an addressable object (at the gimple level) so there can't
really be a dependency.
