This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ppc64 minimal-toc problem.
- To: Geoff Keating <geoffk at redhat dot com>
- Subject: Re: ppc64 minimal-toc problem.
- From: Alan Modra <amodra at bigpond dot net dot au>
- Date: Tue, 17 Jul 2001 21:43:21 +0930
- Cc: gcc-patches at gcc dot gnu dot org, dje at watson dot ibm dot com
- References: <20010717144304.F14490@bubble.sa.bigpond.net.au> <200107170721.AAA08416@geoffk.org> <20010717165901.I14490@bubble.sa.bigpond.net.au> <200107170948.CAA08539@geoffk.org>
On Tue, Jul 17, 2001 at 02:48:03AM -0700, Geoff Keating wrote:
> > From: Alan Modra <amodra@bigpond.net.au>
> > On Tue, Jul 17, 2001 at 12:21:25AM -0700, Geoff Keating wrote:
> > >
> > > which is pretty much what I'd expect, although I suspect 'mfcr' is not
> > > an instruction GCC should really be using...
> >
> > I was using 3.0 branch sources, unchanged. configured with
> > --host=i686-linux --target=powerpc-ibm-aix5.1 --enable-languages=c,
> > gcc/Makefile modified to set {,MAYBE_}USE_COLLECT2 null to get around a
> > build problem, then "-O2 -maix64 -mminimal-toc" gives me
> >
> > .foo:
> > ld 30,LCTOC..1(2)
> > ld 0,0(3)
> > ld 9,LC..0(30)
> > and. 9,0,9
> > mfcr 3
> > rlwinm 3,3,3,1
> > blr
>
> That's interesting. Have you tried debugging the problem? As I said,
> it seems to work on the mainline.
Mainline works for me too. On the branch, I'm seeing .19.lreg
(insn 47 11 52 (parallel[
(set (reg:CC 91)
(compare:CC (and:DI (reg:DI 83)
(const_double (const_int 0 [0x0]) -2147483648 [0x80000000] 0 [0x0]))
(const_int 0 [0x0])))
(clobber (scratch:DI))
(clobber (scratch:CC))
] ) 268 {*anddi3_internal2} (insn_list 11 (nil))
(expr_list:REG_DEAD (reg:DI 83)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (scratch:CC)
(nil)))))
turning into .20.greg
(insn 56 11 57 (use (const_double (mem/u/f:DI (symbol_ref/u:DI ("*LC..0")) 5) -2147483648 [0x80000000] 0 [0x0])) -1 (nil)
(nil))
(insn 57 56 47 (set (reg:DI 9 r9)
(mem/u:DI (plus:DI (reg:DI 30 r30)
(const:DI (minus:DI (symbol_ref/u:DI ("*LC..0"))
(symbol_ref:DI ("*LCTOC..1"))))) 6)) 294 {*movdi_internal64} (nil)
(nil))
(insn 47 57 52 (parallel[
(set (reg:CC 68 cr0 [91])
(compare:CC (and:DI (reg:DI 0 r0 [83])
(reg:DI 9 r9))
(const_int 0 [0x0])))
(clobber (reg:DI 9 r9))
(clobber (scratch:CC))
] ) 268 {*anddi3_internal2} (insn_list 11 (nil))
(nil))
This being the only use of the toc and r30 in this function, we run into
a problem as reload doesn't set regs_ever_live for r30.
On the other hand, mainline puts the constant in the toc during initial
rtl generation, apparently due to differences between mainline and branch
rs6000.c:logical_operand; The mainline version returns 0 for
const_double (0, 0x80000000) while the branch returns 1. One solution
for my testcase then is to install the mainline version of logical_operand
to the branch, but I'm worried that there might be other cases where the
toc is used for the first time during reload.
Alan Modra
PS. I see I mailed my patch to gnu.gcc.org instead of gcc.gnu.org. If
anyone wants a copy, please ask.