https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |matz at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't look to me like RA issue, but rather incorrect coalescing of temporary
vars.
Optimized dump has:
<bb 2> [local count: 1652516]:
ivtmp.40_47 = (unsigned long) &h;
_30 = ivtmp.40_47 + 96;
<bb 3> [local count: 13370357]:
# ivtmp.40_38 = PHI <ivtmp.40_47(2), ivtmp.40_44(3)>
_21 = (void *) ivtmp.40_38;
MEM[(long int *)_21] = 1;
MEM[(long int *)_21 + 8B] = 1;
ivtmp.40_44 = ivtmp.40_38 + 16;
if (_30 != ivtmp.40_44)
goto <bb 3>; [89.00%]
else
goto <bb 4>; [11.00%]
<bb 4> [local count: 1652516]:
h ={v} {CLOBBER};
<bb 5> [local count: 13370357]:
# ivtmp.30_29 = PHI <ivtmp.30_48(5), ivtmp.40_47(4)>
_31 = (void *) ivtmp.30_29;
MEM[(long int *)_31] = 1;
MEM[(long int *)_31 + 8B] = 1;
ivtmp.30_48 = ivtmp.30_29 + 16;
if (_30 != ivtmp.30_48)
goto <bb 5>; [89.00%]
else
goto <bb 6>; [11.00%]
<bb 6> [local count: 1652516]:
f = 2;
e = 6;
c = 1;
b = &d;
d[6] = &d;
ff ();
d ={v} {CLOBBER};
_5 = h[3][0];
_18 = (int) _5;
h ={v} {CLOBBER};
return _18;
So, the code initializes the whole h array, then has h ={v} {CLOBBER};, then
initializes it again, but unfortunately without mentioning the var in the IL -
it reuses ivtmp.40_47 for that, then sets various vars, including d[6]
initialization with &d escaping, clobbers d, reads from h and finally clobbers
h again. I guess the var partitioning code from the above thinks h isn't
really live in between the first h clobber and h[3][0] load and so decides:
Partition 0: size 96 align 16
h d
and places both h and d into the same stack slot.
