This is the mail archive of the gcc-patches@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-regalloc.c patch


Daniel Berlin <dberlin@redhat.com> writes:

> On Fri, 2 Feb 2001, Denis Chertykov wrote:
> 
> >
> > Fri Feb  2 00:30:43 2001  Denis Chertykov  <denisc@overta.ru>
> >
> > 	* new-regalloc.c (x_okay_in_direction): Renamed to
> > 	`x_okay_all_hard_regs' because we don't use direction.
> Fine.

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".
So,
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
> with.

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
> in.
> currReg is not a pseudo.

Example:
- I have an 20 registers 8bit each;
- currReg is 16;
- mode is SImode (4 registers).

Source code:

  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))
	return 0;
    }
  return 1;

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



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