https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #27)
> (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.
> 112: r214:SI=r109:SI-0x60
> 115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
> 117: r217:SI=r109:SI-0x60
> 118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
> 116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]
but 115 doesn't store at the same address as 119? Yes, it has the same
value.
So it doesn't seem to be stack-slot sharing. When we'd share D.33805
with *_179 then we'd have made D.33805 TREE_ADDRESSABLE and adjusted
points-to sets accordingly in update_alias_info_with_stack_vars.
