This is the mail archive of the gcc-patches@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: Bug in egcs-1.1 (reduced testcase included)(PPC)



  In message <9808161700.AA29462@marc.watson.ibm.com>you write:
  >	Instead of having a dedicated zero register like Mips,
  > POWER/PowerPC treats r0 differently for some instructions.  When used as a
  > source operand, most of the time it refers to GPR 0 but sometimes means
  > the constant 0.  In the case of cal|addi|la used by elf_low (as well as
  > cau|addis), r0 is interpreted as the constant 0.
OK.

  > 	r0 actually could be used as the destination for elf_high; but,
  > because it immediately would be fed into elf_low, that normally would
  > require unnecessary shuffling to match elf_low's required constraints.
OK.  So basically we're hosed because of the elf_low pattern.  ie,
even if we fixed elf_high, we're going to have the same problem with
elf_low since the elf_high typically feeds directly into an elf_low.

  > 	The real problem is reload choosing r0 to restore the symbol_ref.
  > "b" are BASE registers to be used for address calculations.  r0 is the
  > only register that should not be used that way.  Instead of all of this
  > work to make r0 usable, is there any way to tell reload to avoid r0 for
  > these types of fixups of symbol_refs?
Nope.  No way I'm aware to directly prevent reload from using r0 for
this one specific case.

Basically reload realizes that it needs to load the value of the
symbol_ref into a register.  It will select *any* hard register which
can hold SImode values for the reload register, including r0.  There's
no way for the compiler to know that r0 is special at the time where
the reload register is selected.

We could define LIMIT_RELOAD_CLASS to return BASE_REGS when presented
with SImode and GENERAL_REGS as arguments.  That would basically prevent
reload from ever using r0 for a SImode reload.  I don't know the ppc
port well enough to guess if this might be a suitable solution.

The other approach is to define secondary reloads.   To do that 
accurately, we need to create the R0_REGS register class, then have
secondary_reload_class return BASE_REGS when presented with a load
of a symbol_ref into R0_REGS.



jeff


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