[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-27
     Ever Confirmed|0                           |1

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-27 17:30:26 UTC ---
I've checked in a testcase for this, unfortunately it fails on i686-linux
with -Os -m32.
The problem is that for a[0] there is no struct access created at all, as
before esra we have a accesses solely of the form:
  a = *.LC0;
...
  _5 = MEM[(int *)&a + 8B];
...
  MEM[(int *)&a + 8B] = _6;
...
  _8 = MEM[(int *)&a + 4B];
...
  MEM[(int *)&a + 4B] = _9;
...
  D.1370 = *.LC1;
  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})&D.1370];
...
  _13 = MEM[(int *)&a + 8B];
...
  MEM[(int *)&a + 8B] = _14;
...
  _16 = MEM[(int *)&a + 4B];
...
  MEM[(int *)&a + 4B] = _17;
...
  a ={v} {CLOBBER};

i.e. there is no a[0] or MEM[(int *)&a] access, only two whole aggregate
assignments.

I wonder if SRA could create the the extra hole accesses if there are any whole
aggregate writes, at least if there aren't too many (preferrably with sizes
based on the underlying type fields/elements, and not for any padding).
BTW, even for a[1] and a[2] at -Os -m32 there is a problem, on the memcpy we
end up with:
  D.1370 = *.LC1;
  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})&D.1370];
  a$4_3 = MEM[(int[3] *)&D.1370 + 4B];
  # DEBUG a$4 => a$4_3
  a$8_4 = MEM[(int[3] *)&D.1370 + 8B];
  # DEBUG a$8 => a$8_4