SMALL_REGISTER_CLASSES

[Michael P. Hayes]

Jeffrey A Law writes:
 >   In message < 199801200202.PAA11726@ongaonga.chch.cri.nz >you write:
 >   > 
 >   > Looking through the GCC code I get the impression that
 >   > SMALL_REGISTER_CLASSES has been used to infer that a target has only a
 >   > few registers, rather than its original meaning, where it signified
 >   > that registers explicity mentioned in the RTL had to be used as spill
 >   > registers.
 > No, it still means those registers need to be used as spills, it just happens
 > that machines with few registers tend to also have registers which are
 > explicitly mentioned in RTL and must still be able to use them as spills.

The problem I'm having is that while I have many registers, there is
one rarely used class that is composed entirely of registers that
are explicitly mentioned in the RTL.

I'm loathe to have to define SMALL_REGISTER_CLASSES in general since
it stomps on many optimisations, but I have a rare case where reload
has to spill one of the registers mentioned in the RTL.  From what
I've noticed, reload can safely do it, but it won't without
SMALL_REGISTER_CLASSES defined.

I suggested to J"orn that SMALL_REGISTER_CLASSES requires a hard regno
argument.  J'orn (amylaar@cygnus.co.uk) wrote:

  That would be a quiet substantial change, but I see that some more
  differentiation could make sense.  However, rather than a regno, I suggest
  to use a register class as an argument. This way, when register allocation /
  reload wants to know about a particular register class, it can get at this
  information easily.  If you want to know about a particular register,
  you'd use SMALL_REGISTER_CLASSES (REGNO_REG_CLASS (regno)).

Most of the time SMALL_REGISTER_CLASSES is used when there is also a
test to see if regno is a hard register, so I thought that it could be
combined in the macro.  Besides, this macro shouldn't need to be
defined by each target, since the condition is computable.