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