[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 28 Apr 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> One thing is that store-merging doesn't optimize this, I think we have an open
> enhancement request for that that should be able to cure that case.
> 
> Another one is that perhaps we should consider such MEM_REFs as not necessarily
> forcing the variable into memory, and if that is the only thing to keep it
> addressable, we could in tree-ssa-live.c rewrite it using BIT_INSERT_EXPR.

Indeed, for the case we can rewrite the variable into SSA that should 
work.  If you change 'x' to be struct { int x; int y }; and just use
the x component that trick alone doesn't work - you'd first need SRA
to decompose this.  Oh, interestingly store-merging handles _that_
case just fine:

int replace_bytes_3(int *v1 ,char v2)
{
  memcpy( (void*) (((char*)v1)+1) , &v2 , sizeof(v2) );
  return *v1;
}

int foo3()
{
  struct { int x; int y; } s;
  s.x = 3;
  char c = 1;
  return replace_bytes_3(&s.x,c);
}

Coalescing successful!
Merged into 1 stores
New sequence of 1 stores to replace old one of 2 stores
Merging successful!
foo3 ()
{
  struct
  {
    int x;
    int y;
  } s;
  int _4;

  <bb 2> [local count: 1073741824]:
  MEM[(void *)&s] = 259;
  _4 = MEM[(int *)&s];
  s ={v} {CLOBBER};
  return _4;

with then optimal assembly.