This is the mail archive of the
mailing list for the GCC project.
Re: new-regalloc.c patch
- To: Daniel Berlin <dberlin at redhat dot com>
- Subject: Re: new-regalloc.c patch
- From: Denis Chertykov <denisc at overta dot ru>
- Date: 02 Feb 2001 20:15:39 +0300
- Cc: Denis Chertykov <denisc at overta dot ru>, <gcc-patches at gcc dot gnu dot org>
- References: <Pine.LNX.email@example.com>
Daniel Berlin <firstname.lastname@example.org> writes:
> On Fri, 2 Feb 2001, Denis Chertykov wrote:
> > Fri Feb 2 00:30:43 2001 Denis Chertykov <email@example.com>
> > * new-regalloc.c (x_okay_in_direction): Renamed to
> > `x_okay_all_hard_regs' because we don't use direction.
Must I apply it ?
> > (edge_weight): Weight of edge between v1 and v2 equal to hard
> > regs count in v2.
> This is wrong.
> The edge weight is dependent on the number of hard regs in both. The
> reason i left out the other cases is because i couldn't figure them out in
> my head, and they didn't seem to crop up.
> edge_weight (v1,v2) is directly dependent on how much v2 can block
> coloring of v1, and v1 can block coloring of v2.
v2 of v1 and v1 of v2 isn't the same.
As I understand:
edge_weight (v1,v2) is "how much v2 can block coloring of v1";
edge_weight (v2,v1) is "how much v1 can block coloring of v2".
edge_weight (v1,v2) + edge_weight (v2,v1)
== (CLASS_MAX_NREGS (reg_preferred_class (v1), PSEUDO_REGNO_MODE (v1)
+ CLASS_MAX_NREGS (reg_preferred_class (v2), PSEUDO_REGNO_MODE (v2))
IE: For edge_weight (v1,v2): v2 can block
CLASS_MAX_NREGS (regclass-v2, mode-of-v2) colors of v1.
(IMHO: I can be wrong here, but I don't know where.)
> Think of edge weighting as an alternative to having multiple nodes, one
> for each hard reg needed by the pseudo.
> They would interfere with each other, and everything the pseudo interferes
My previous thought derived from "to having multiple nodes, one for
each hard reg needed by the pseudo."
> > (x_okay_in_direction): Removed `HARD_REGNO_MODE_OK' from
> > cycle. Because we can't test each hard regs in currReg for
> > mode MODE.
> I don't get this.
> I need to rename currReg in that funciton (speaking of which, i'm about to
> rename all the functions/varaibles to conform to standards, since i'm
> sufficiently convinced i've implemented the basic algorithm right, and
> thus, don't need to check it against the paper anymore). We are trying to
> figure out whether the current hard register is okay to store this mode
> currReg is not a pseudo.
- I have an 20 registers 8bit each;
- currReg is 16;
- mode is SImode (4 registers).
for (k = 1; k < num_regs; k++)
int regno = curr_reg + k;
if (regno < 0
|| ! TEST_HARD_REG_BIT (okay, regno)
|| ! HARD_REGNO_MODE_OK (regno, mode))
So, your program tests
HARD_REGNO_MODE_OK (16, SImode); /* Unnecessary because caller tests this */
HARD_REGNO_MODE_OK (17, SImode); /* Wrong */
HARD_REGNO_MODE_OK (18, SImode); /* Wrong */
HARD_REGNO_MODE_OK (19, SImode); /* Wrong */
Fragment from gcc.info:
`HARD_REGNO_MODE_OK (REGNO, MODE)'
A C expression that is nonzero if it is permissible to store a
value of mode MODE in hard register number REGNO (or in several
On some machines, double-precision values must be kept in even/odd
register pairs. The way to implement that is to define this macro
to reject odd register numbers for such modes.