As reported here http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02071.html, we
now produce worse code for PPC64 Linux (and PPC AIX).
We produce now produce worse code for gcc.dg/20020103-1.c on powerpc64
with TOCs (and the stack space goes up, 256 vs 272).
Before IRA we emitted:
ld 3,[EMAIL PROTECTED](2)
but after we had spill the address to the stack which is wrose:
--- before.s 2008-08-28 02:14:27.000000000 +0900
+++ after.s 2008-08-28 02:14:13.000000000 +0900
@@ -40,8 +40,9 @@ bar:
std 27,-40(1)
std 28,-32(1)
std 29,-24(1)
- stdu 1,-256(1)
+ stdu 1,-272(1)
lwzu 5,4(31)
+ std 9,112(1)
lwa 4,0(30)
lwa 3,0(9)
extsw 5,5
@@ -52,12 +53,13 @@ bar:
#asm
# 0 "" 2
#NO_APP
+ ld 9,112(1)
mr 4,30
- ld 3,[EMAIL PROTECTED](2)
mr 5,31
+ mr 3,9
bl f2
nop
- addi 1,1,256
+ addi 1,1,272
ld 0,16(1)
ld 14,-144(1)
mtlr 0
Also if we are going to spill it to memory, then why use another
register and not just r3?
Note the comment on the testcase is incorrect:
/* Verify that constant equivalences get reloaded properly, either by being
spilled to the stack, or regenerated, but not dropped to memory. */
We do regnerate it so the check should not be done on lP64 Powerpc (or
any PowerOpen [TOC] based ABIs); I should mention that powerpc64 elf
has @got but xcoff does not have a @got which is why GCC uses the old
way of producing the TOC section.
Also note this testcase now passes on 32bit PPC Linux but that is only because
we spill the address instead of recreating it.
I bet this is a generic issue too and causes performance issues and stack usage
on more than just PowerPC 64.
--
Summary: [4.4 Regression] IRA does not re-materializes addresses
(loads from the TOC)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273
