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
