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

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Jeffrey A Law writes:

Jeff> We see that (reg r0) is not suitable for use as a destination
Jeff> in the elf_high or as a source in elf_low.  This causes the compiler
Jeff> to abort later because the constraints do not match.

Jeff> The way to deal with this problem is to either allow reg0 in those
Jeff> patterns or to allocate secondary reload reg when copying a symbol_ref
Jeff> into GENERAL_REGS (well, we should really make a class of r0, then
Jeff> allocate the secondary reload when copying a symbol_ref into R0_REGS).

Jeff> I don't know anything about the rs6000/ppc ISA, so I don't know if
Jeff> there's some real reason why we can't use r0 in those instructions.

Jeff> If there's no reason why we can't use r0, then the best solution is
Jeff> to allow r0 -- it's simpler and will generate better code.

	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.

	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.

	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?

David