Re: Bug in egcs-1.1 (reduced testcase included)(PPC)

[Jeffrey A Law <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
  > construction. 
Again, this is precisely the kind of thing secondary reloads are supposed 
to handle.  A secondary reload can be required for either inputs, outputs
or both.

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
target register.

  > 	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
	register (r0).

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

jeff