Re: Patch: inv_reg_alloc_order

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.LNX.4.04.9911281120190.7880-100000@pathia.cygnus.co.uk>you w
rite:
  > > You're introducing a behavior which is different from the other places
  > > where we look at the ordering of registers for allocation/reloading.  Tha
  > t
  > > seems like a poor design.
  > 
  > I'm not introducing it.  order_regs_for_reload is already using a different
  > order than the register allocators.
It's clear that I haven't been able to clearly state why I think this is a
bad idea [FWIW, after reviewing all the mail, the register allocators and
reload I still think it's bad, though possibly not as bad as before. ]

I can guess that you to make the change for use in order_regs_for_reload;
and if you look at just the implications in reload it seems like a reasonable
thing to do.

What I'm objecting to is the confusion this adds in global,c local-alloc.c,
resource.c and stupid.c.

Right now the rules regarding REG_ALLOC_ORDER and reg_alloc_order are very
simple to understand.  If REG_ALLOC_ORDER is defined, then we always use
reg_alloc_order, else we do not use reg_alloc_order.

With your change we'll have some code (global, local, resource & stupid)
which adhere to the old rules (use reg_alloc_order iff REG_ALLOC_ORDER is
defined, else do not use reg_alloc_order).  While other code (reload) will
unconditionally use reg_alloc_order regardless of the state of REG_ALLOC_ORDER.
Which is rather non-intuitive.

One way to address this is to always initialize and use reg_alloc_order.  The
problem with this solution is the way you've choosen to initialize
reg_alloc_order when REG_ALLOC_ORDER is not defined is rather different than
what local, global, resource & stupid want (and how the compiler is documented
as working).

One option would be to make the initialization work in the manner expected
by the other users of reg_alloc_order.  That would mean reload would behave
differently than before.  Though I doubt in any significant ways.

However, it also seems to me that we do not have to resolve this issue for
your patch to go in.  I believe the ultimate motivation behind these changes
was to improve the generated code.  If so, we can go ahead with your patch
(so that it gets tested) and iterate on this issue until we reach an
agreement on way or the other.

--

On a related note, I do want code to provide an inverse of the register
allocation order.  There's a place in global.c where it needs to be used
(when we're looking for a hard register that was allocated by local-alloc, but
which could be better used by global-alloc).


jeff