This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Painful problems with -fpic implementation on powerpc-sysv


>>>>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]