This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New register allocator branch created (fwd)




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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]