regclass oddity?

["Dave Korn" <dave dot korn at artimi dot com>]

    Hi all,

  When regclass determines that placing an operand into either one of several
register classes would have the same cost, it picks the numerically highest
one in enum reg_class ordering.

  In my particular circumstances this is not good, because a lot of the
high-numbered reg classes (which correspond to special-purpose registers) only
have one member in them.  I am aware of the ordering rule that says that class
x must be numerically lower than class y if y is a superset of x, but in this
case the classes are entirely disjoint.

  What makes it even worse is that regclass insists on picking these classes,
despite the fact that a) there is no way to load a memory operand into one, it
has to go via a secondary reload into a GPR, and b) there is no way to load an
immediate constant into one either.  The only way to access these registers is
via a gpr.

  So, is there actually anything inconsistent or incorrect about setting up my
reg classes in this fashion?

#define REG_CLASS_CONTENTS {          \
    { 0x00000000, 0x00000000, 0x00000000 },     /* NO_REGS      */ \
    { 0xffffffff, 0xffffffff, 0x00000000 },     /* GENERAL_REGS */ \
    { 0x00000000, 0x00000000, 0x00000001 },     /* MPD_REG 64 */ \
    { 0x00000000, 0x00000000, 0x00000002 },     /* MPR_REG 65 */ \
    { 0x00000000, 0x00000000, 0x00000004 },     /* MPRA_REG 66 */ \
    { 0x00000000, 0x00000000, 0x00000008 },     /* MPRL_REG 67 */ \
    { 0x00000000, 0x00000000, 0x00000010 },     /* MPRH_REG 68 */ \
    { 0x00000000, 0x00000000, 0x00000020 },     /* MPC_REG 69 */ \
    { 0x00000000, 0x00000000, 0x00000040 },     /* MPV_REG 70 */ \
    { 0x00000000, 0x00000000, 0x00000080 },     /* MPRLS_REG 71 */ \
    { 0x00000000, 0x00000000, 0x00000100 },     /* MPAR_REG 72 */ \
    { 0x00000000, 0x00000000, 0xffffffff },     /* SPECIAL_REGS */ \
    { 0xffffffff, 0xffffffff, 0xffffffff }      /* ALL_REGS     */ \
}

  I might be able to 'disguise' the problem by moving GENERAL_REGS after
SPECIAL_REGS, so that it would be picked if it was as favourable as any other,
but I'm curious: should regalloc really not care about the size of classes?
ISTM that given an equal cost for putting some operand into a class with 1
member and a class with 32 members, it would be highly preferable to choose
the bigger class to try and avoid register pressure.  The nearest I can see to
any such logic in regclass would be the part of record_reg_classes that says 

  /* If this insn is a single set copying operand 1 to operand 0
     and one operand is a pseudo with the other a hard reg or a pseudo
     that prefers a register that is in its own register class then
     we may want to adjust the cost of that register class to -1.

but that isn't coming into play in this case because it only cares about
reg->reg moves and I'm having trouble with a mem->reg move.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....