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.