https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595
--- Comment #4 from Pat Haugen pthaugen at gcc dot gnu.org ---
Created attachment 33775
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33775action=edit
unreduced bzip2 testcase
CPU2006 benchmark 447.dealII started segfaulting on PowerPC with revision
216305. Sorry for unreduced testcase, but wanted to get info out. ICF is
commoning functions, but doing so incorrectly. Atached .bzip2 file can be
compiled with 'g++ -S -m64 -O2 -mcpu=power7 tria.ii' to show the problem.
Looking at the generated assembler, the following 3 functions:
_ZNK13TriangulationILi3EE8end_faceEv
_ZNK13TriangulationILi3EE7end_hexEv
_ZNK13TriangulationILi3EE3endEv
have all been changed to call '_ZNK13TriangulationILi3EE8end_quadEv' instead of
having equivalent inline code. It appears the code for all 4 functions is the
same in r216304, but with r216305 the 3 named functions are loading gpr3 with
the addr of a local stack temp before calling
'_ZNK13TriangulationILi3EE8end_quadEv', such that the desired values do not get
stored off the original gpr3 value passed in (see '' line noted below).
Following is generated asm for '_ZNK13TriangulationILi3EE8end_faceEv', the
other two are similar:
r216304:
li 10,-1
std 4,8(3)
stw 10,0(3)
stw 10,4(3)
blr
216305:
mflr 0
std 0,16(1)
stdu 1,-128(1)
.cfi_def_cfa_offset 128
.cfi_offset 65, 16
addi 3,1,112
bl _ZNK13TriangulationILi3EE8end_quadEv
nop
addi 1,1,128
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
blr
A side comment about the above ICF tranformation, it sure seems like this is
going to degrade performance. We've went from a simple stackless leaf function
to one that stacks a frame and makes a call.
