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: patch for local alloc / global alloc / reload problem



  In message <199808260504.BAA07116@jwlab.FEITH.COM>you write:
  > This change allows gcc to attempt and find a hard register
  > for a pseudo register which was allocated to a hard register
  > by local-alloc and later spilled by reload.  The effect of
  > the patch can be seen by compiling:
Cool.  Something we've needed for a long time.  If/when we install
this you should also change this comment near the top of local-alloc.c.

/* Pseudos allocated here cannot be reallocated by global.c if the hard
   register is used as a spill register.  So we don't allocate such pseudos
   here if their preferred class is likely to be used by spills.  */


Once installed, we can then play with allowing local-alloc to allocate 
regs that are "likely to be spilled" to see if we generally get better
code or not.


  >   1) There may be some overlap between this patch and work
  >      that Bernd Schmidt is doing.
I don't think so.  Though Bernd's patch will make this less important
since when we do spill, we only spill the pseudo that was live at
the point where we needed the reload reg instead of all psuedos which
were assigned to the reload reg.

But even with Bernd's patch, I think we still want the ability to
have global re-assign pseudos which were allocated hard regs by
local allocation.


  >   2) I could use a quick description of what reg_may_share
  >      does.
Well...  It's actually "regs_may_share" is a bad name.  It should be
called "regs_must_share".

Basically a pair of regs in the regs_may_share must be allocated to
the same hard register.

I believe it is only used by loop when moving a bunch of movables
that have the same value.  It'll initialize the first movable, then
emit a series of copy insns to initialize the remaining movables that
have the same value.  Presumably the copy insns are removed by the
nop-move code in the final jump.c pass.


  > ChangeLog:
  > 
  > Wed Aug 26 00:04:27 EDT 1998  John Wehle  (john@feith.com)
  > 
  > 	* global.c (global_alloc): Assign allocation-numbers
  > 	even for registers allocated by local_alloc in case
  > 	they are later spilled and retry_global_alloc is called.
  > 	(mark_reg_store, mark_reg_clobber,
  > 	mark_reg_conflicts, mark_reg_death): Always record a
  > 	conflict with a pseudo register even if it has been
  > 	assigned to a hard register.
  > 	(dump_conflicts): Don't dump pseudo registers already
  > 	assigned to a hard register.
A note about patches.  Please include "-p" when you make your diffs;
that encodes the name of the function that's being changed in the
hunk headers, which makes the patch easier to read.

You need to change a couple comments in global.c.

   1. count the pseudo-registers still needing allocation
   and assign allocation-numbers (allocnos) to them.
   Set up tables reg_allocno and allocno_reg to map
   reg numbers to allocnos and vice versa.
   max_allocno gets the number of allocnos in use.
[ ... ]

/* Number of pseudo-registers still requiring allocation
   (not allocated by local_allocate).  */

static int max_allocno;

/* Indexed by (pseudo) reg number, gives the allocno, or -1
   for pseudo registers already allocated by local_allocate.  */

int *reg_allocno;


I wonder if it makes more sense to go ahead and show the conflicts
for stuff allocated by local-alloc -- such information will be
critical if/when we need to debug code where we ended up re-assigning
a psuedo allocated by local-alloc.

One more thing to check -- sometimes global will kick regs allocated
by local out of their hard register.  Presumably your changes will
allow us to try and have global find a new hard register for such
pseudos (see global.c::find_reg)?  You might try some tests to see
if it actually works.

Otherwise it looks good!  I think we just need to deal with the comments
and install the change.  Then we can look at some of the other issues
that are opened up by having this capability.



jeff


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