This is the mail archive of the
mailing list for the GCC project.
Re: Bug in egcs-1.1 (reduced testcase included)(PPC)
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: Bug in egcs-1.1 (reduced testcase included)(PPC)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 17 Aug 1998 01:22:43 -0600
- cc: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, egcs-patches at cygnus dot com, Michael Meissner <meissner at cygnus dot com>, Hartmut Koptein <koptein at et-inf dot fho-emden dot de>
- Reply-To: law at cygnus dot com
In message <9808170613.AA26244@marc.watson.ibm.com>you write:
> >>>>> Jeffrey A Law writes:
> >> Setting up SECONDARY_RELOADS for this case is a mistake, IMO.
> Jeff> Well, that's how most other ports deal with this kind of problem. In
> Jeff> fact, this kind of problem is precisely what secondary reloads are fo > r.
Actually, LIMIT_RELOAD_CLASS won't work. The docs fail to mention it
only applies to SUBREG thingies. Ugh.
I think we have to use secondary reloads to fix this. Ugh.
> If the real problem was how to get the base address into r0,
> SECONDARY_RELOADS would be the solution. However, what the compiler is
> trying to accomplish is wrong for the PowerPC ISA. r0 can be used for
> displacement load instructions, but the compiler is trying to construct a
> PIC address which cannot use r0 as the source for the intermediate
Again, this is precisely the kind of thing secondary reloads are supposed
to handle. A secondary reload can be required for either inputs, outputs
At the time when we have to worry about this no distinction is made
between the high and low parts. We're just trying to load a symbol_ref
into a register. Splitting the load up into high/low parts happens
entirely behind the back of reload.
What we want to do with secondary reloads in this case is describe
this concept to the compiler:
"You can not directly copy a SYMBOL_REF (or LABEL_REF) into register r0;
instead an additional register must be used as an intermediate."
Which is accomplished by simply having secondary_reload_class return
BASE_REGS when it encounters a copy from a SYBMOL_REF which might end
up using r0. This forces reload to allocate an additional reg to be
used as an intermediate register. ie the symbol_ref will be loaded
into the base register, then the base register will be copied to the
> Maybe I don't fully understand how reload uses SECONDARY_RELOADS,
> but teaching the compiler to use base registers as intermediaries for
> loading r0 doesn't seem like it will prevent this problem.
I don't think you understand secondary reloads :-) The key things
to remember for this particular case are:
* We're trying to load a SYMBOL_REF into a register. Reload
does not see the elf_high/elf_low stuff.
* Normally we'll just allocate one reload register for this
case. We'll call gen_movsi (reloadreg, (SYMBOL_REF ...)
And the movsi expander explodes this into the elf_high/elf_low
components. The dest of the elf_high and source fo the elf_low
insns will be the single reload register.
* If we choose r0 as the reload register we lose.
* By defining a secondary reload we direct the compiler to
first copy the SYMBOL_REF into the intermediate register, then
to copy the intermediate register to the ultimate reload
> Why wouldn't
> reload load HIGH into a base register, move it to r0 and then proceed to
> try to add the rest of the symbol_ref using r0 which is the real pattern
> that cannot match those constraints?
Because reload never sees the HIGH/LO_SUM insns. Reload simply wants
to do gen_movsi (reloadreg, (SYMBOL_REF))
The expansion into HIGH/LO_SUM components happens via the movsi expander.
> Will the SECONDARY_RELOAD affect the
> entire symbol_ref reload into r0 or just one of the steps?
It effects the entire symbol_ref reload.