Re: New register allocator branch created (fwd)

[Jim Wilson <wilson at cygnus dot com>]

In article <Pine.LNX.4.31.0101281915340.18469-100000@www.cgsoftware.com> you write:
>This problem is caused by this pseudo having a preferred class of
>INDEX_REGS and an alternate of GENERAL_REGS, even though it *can't* use
>GENERAL_REGS.

The register class preferences aren't perfect.  They can't be.  It is possible
for a single pseudo to be used by two different instructions that require
disjoint register classes.  A common example is a pseudo that needs to be both
an integer register and an FP register.  All we can do is choose the register
class that satisfies the most uses, giving extra weight to uses that occur
inside loops.  The class that is second best is then the alternative register
class, as long as it is cheaper than memory.  It is usually better to assign
a register, even if it is the wrong class, because reloading from general regs
to index regs is a lot cheaper than reloading from a stack slot.  There are
cost calculations to try to make sure that a class is cheaper than memory even
if it doesn't satisfy all uses of the pseudo.  We then rely on reload to fix
all cases where we allocated a pseudo to a different reg class than what the
instruction requires.

If you need perfect register classes, then you will have to change regscan.
You could perhaps renumber pseudo's, inserting copy instructions from the old
pseudo to the new pseudo, when you encounter a register class conflict.
If you already have live range splitting, you can probably make use of that
to handle this problem.

Jim