Problem in gen_reload(), seeking an explanation

[Franz Sirl]

At 16:55 21.06.99 , Joern Rennecke wrote:
> >            || (GET_CODE (op1) == REG
> > -             && REGNO (op1) >= FIRST_PSEUDO_REGISTER))
> > +             && REGNO (op1) >= FIRST_PSEUDO_REGISTER)
> > +         || (GET_CODE (op0) == REG
> > +             && REGNO (op0) < FIRST_PSEUDO_REGISTER
> > +             && REGNO_REG_CLASS (REGNO (op0)) == GENERAL_REGS))
> > +             && GET_CODE (op1) == REG
> > +             && REGNO (op1) < FIRST_PSEUDO_REGISTER
> > +             && REGNO_REG_CLASS (REGNO (op1)) != GENERAL_REGS))
>
>REGNO_REG_CLASS will always give you a smallest register class that a
>register belongs to.  So you might get a subclass of GENERAL_REGS.
>Examples are the various letter-named one-register-classes on x86,
>M16_REGS on mips, R0_REGS on SH.
>
>So it's better to say:
>
>TEST_HARD_REG_BIT (reg_class_contents[GENERAL_REGS], REGNO (op0))

OK, understood. Do I have to care about a FLOAT_REGS = FLOAT_REGS + 
GENERAL_REGS case here? Just to make sure I'm not breaking anything.

>but that will still not handle the case properly when an add can
>operate on some register class that is not a subset of GENERAL_REGS.
>I don't know if we have any target where this is an issue, though.

Uhm, such an argument would probably point to a solution with 
gen_rtx_SET(gen_rtx_PLUS()) instead of gen_add2_insn for insn validation 
again? Otherwise you would have to put a lot of checking into the swap 
decision and probably need a new backend macro.

Franz.