[Bug tree-optimization/64601] Missed PRE on std::vector move assignment

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> Actually there is no need for inlining.
> 
> struct A { int i; };
> void f(struct A *a){ *&a->i=0; }
> void g(struct A *a){ int*p=&a->i;*p=0; }
> 
> The main difference seems to be that the first one gets through fold-const.c
> while the second is handled by tree-ssa-forwprop.c.

&a->i is merely an address calculation, not an access to type A at a.  Thus
it's valid to write

 struct B { int i; int j; };
 struct B b;
 int *p = &((struct A *)&b)->i;
 *p = 0;

and it's only required that the actual access (here a int * dereference)
honors TBAA rules.

So generally you can't "reconstruct" access paths when forwarding address
calculations into dereferences.  We've had very elaborate code "guessing"
access paths in oder releases which broke down very easily for moderately
complex testcases.

We still have some of that code in forwprop (I still believe it's not
100% correct...) which handles

struct A { int i[4]; };
void g(struct A *a, int j) { int *p = &a->i[j]; *p = 0;}

generating

  MEM[(int *)a_1(D)].i[j_2(D)] = 0;
  return;

but the case comes after forwarding invariant addresses.  If we'd swap them
(really believing in its correctness) then we also handle your case.
But as I said - that "If ... and the value type is the same as that of the
pointed-to type of the address" is really bogus - the type of the address
doesn't have any meaning in GIMPLE (all pointer type conversions are
useless).