New register allocator branch created (fwd)

Daniel Berlin dberlin@redhat.com
Mon Jan 29 15:14:00 GMT 2001


On Mon, 29 Jan 2001, Jim Wilson wrote:

> 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.

Here's the thing, reload doesn't fix it.
It gets output into asm, and you get an assembler error saying it can't be
used as an index register.
Is *this* a bug?
>
> 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 i can solve the problem i'm getting renumbering pseudo's, i'll do this.

> If you already have live range splitting, you can probably make use of that
> to handle this problem.
>
> Jim
>



More information about the Gcc mailing list