https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-01-12
CC| |jakub at gcc dot gnu.org,
| |meissner at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think I can reproduce it with powerpc64le-linux too (though, have just
eyeballed assembly, not tried to run it).
This looks like an IRA or reload problem to me.
In *.ira we have 12 loads from *.LANCHOR0 first (8 DImore reads from *.LC0 and
4 DImore reads from *.LC1), followed by stores to stack locations:
5: r172:DI=unspec[`*.LANCHOR0',%2:DI] 47
REG_EQUIV `*.LANCHOR0'
41: %4:DI=0xd
6: r173:DI=[r172:DI]
REG_EQUIV [r172:DI]
8: r174:DI=[r172:DI+0x8]
REG_EQUIV [r172:DI+0x8]
10: r175:DI=[r172:DI+0x10]
REG_EQUIV [r172:DI+0x10]
12: r176:DI=[r172:DI+0x18]
REG_EQUIV [r172:DI+0x18]
14: r177:DI=[r172:DI+0x20]
REG_EQUIV [r172:DI+0x20]
16: r178:DI=[r172:DI+0x28]
REG_EQUIV [r172:DI+0x28]
18: r179:DI=[r172:DI+0x30]
REG_EQUIV [r172:DI+0x30]
20: r180:DI=[r172:DI+0x38]
REG_EQUIV [r172:DI+0x38]
23: r182:DI=[r172:DI+0x40]
REG_EQUIV [r172:DI+0x40]
25: r183:DI=[r172:DI+0x48]
REG_EQUIV [r172:DI+0x48]
27: r184:DI=[r172:DI+0x50]
REG_EQUIV [r172:DI+0x50]
29: r185:DI=[r172:DI+0x58]
REG_DEAD r172:DI
REG_EQUIV [r172:DI+0x58]
42: %3:DI=sfp:DI+0x68
7: [sfp:DI+0x60]=r173:DI
REG_DEAD r173:DI
9: [sfp:DI+0x68]=r174:DI
REG_DEAD r174:DI
...
Now, IRA decides to put pseudo 172 as well as pseudo 185 into r9, but pseudos
173-175 have mem disposition. Reloads changes this into:
...
25: %8:DI=[%9:DI+0x48]
REG_EQUIV [%9:DI+0x48]
27: %10:DI=[%9:DI+0x50]
REG_EQUIV [%9:DI+0x50]
29: %9:DI=[%9:DI+0x58]
REG_EQUIV [%9:DI+0x58]
42: %3:DI=%1:DI+0x68
107: %31:DI=[%9:DI]
7: [%1:DI+0x60]=%31:DI
108: %31:DI=[%9:DI+0x8]
9: [%1:DI+0x68]=%31:DI
...
which means that the load results that had MEM dispositions are moved next to
the stores and somehow expect r9 at that point is still holding *.LANCHOR0
address, but it holds something different. The bug goes away with -mlra it
seems. IRA computes the same dispositions, but LRA seems to ignore the fact
that pseudo has been assigned r9 and uses r30 instead for it, so everything is
fine.
