Re: Patch: inv_reg_alloc_order

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

  In message <Pine.LNX.4.04.9911271557340.7468-100000@pathia.cygnus.co.uk>you w
rite:
  > This patch adds a new array, inv_reg_alloc_order.  I'm going to use this in
  > the next version of my reload patches.  While I was there, I also made
  > reg_alloc_order defined for every target; if REG_ALLOC_ORDER isn't defined
  > it will prefer call-used regs over call-saved ones (this happens to be what
  > I need in the reload patch, and no other place in the compiler uses
  > reg_alloc_order in this case yet).
My gut tells me that your handling of REG_ALLOC_ORDER is just going to
ultimately confuse things.

Right now the lack of a definition of REG_ALLOC_ORDER causes registers
to be used in increasing order.

After your patch that rule is no longer true since in some places I'm assuming
you'll use reg_alloc_order, which is not necessarily going to contain the
registers in linear order.  Search for REG_ALLOC_ORDER in the register
allocators and reload passes.

If we're going to move in this general direction I suggest we do away with all
the code that is conditional on REG_ALLOC_ORDER.  Furthermore, I'd recommend
that we initialize reg_alloc_order as 0, 1, 2, 3 ... when  REG_ALLOC_ORDER is
not defined.

These issues seem related enough that they should be dealt with at the same
time.  Also note if we do not go with the default ordering I suggested above,
then I suspect we need some documentation updates.



jeff