This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Painful problems with -fpic implementation on powerpc-sysv
- To: Geoff Keating <geoffk at ozemail dot com dot au>
- Subject: Re: Painful problems with -fpic implementation on powerpc-sysv
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Thu, 20 Aug 1998 14:04:57 -0400
- Cc: egcs at cygnus dot com, Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, Jeffrey Law <law at cygnus dot com>
>>>>> Geoff Keating writes:
Geoff> (insn 13 11 38 (set (reg:DI 84)
Geoff> (const_double (const_int 0) 0 2146435072)) 425 {*movdi_32} (nil)
Geoff> (expr_list:REG_EQUIV (const_double (const_int 0) 0 2146435072)
Geoff> (nil)))
Geoff> (insn 38 13 14 (set (reg:SI 88)
Geoff> (unspec[
Geoff> (const_int 0)
Geoff> ] 7)) 512 {init_v4_pic} (nil)
Geoff> (nil))
Geoff> But the first insn, number 13, is a memory reference. It doesn't look
Geoff> like it now, but pseudo 84 will be allocated to a floating-point
Geoff> register, and the only way to load a constant into a FP register is
Geoff> from memory. So reload will push the const_double out to a constant
Geoff> memory location. The load from memory will require the GOT pointer.
Geoff> But the GOT pointer is not initialised until the _next_ insn.
FP constants can be materialized in GPRs and transferred to FPRs.
The define_splits for loading CONST_DOUBLEs into FPRs specifically test
reload_completed. The problem seems to be the use of a memory location
that requires the GOT instead of the stack.
Does GCC decide early on that it will construct the constant in
the GOT pool and load from there but then doesn't have the GOT handy? In
these cases is there some way to convince GCC to reload the value directly
via an alternative method instead of from the GOT slot?
David