Patch: inv_reg_alloc_order

Jeffrey A Law
Sun Nov 28 02:58:00 GMT 1999

  In message < >you w
  > Actually, it can be different in every place that tests whether
  > REG_ALLOC_ORDER is defined or not.  The register allocators do in fact use
  > increasing order; order_regs_for_reload uses the order introduced by the
  > patch.
And that's what I object to -- we've got multiple rules for something that
IMHO should have one rule.

It's not a question of what we *can* do, but what we *should* do.

  > > you'll use reg_alloc_order, which is not necessarily going to contain the
  > > registers in linear order.
  > Things won't change with the patch, since currently all uses of
  > reg_alloc_order are protected with a [! defined REG_ALLOC_ORDER]
  > conditional.  There should be no difference in behaviour.
Right.  Things won't change, and that's the problem!

You're introducing a behavior which is different from the other places
where we look at the ordering of registers for allocation/reloading.  That
seems like a poor design.

  > We can either get rid of the REG_ALLOC_ORDER conditional in the register
  > allocators, or the one in reload, but not both.  If you still want things
  > to be ordered by increasing number, I'll update the patch.
Please explain why we need one or the other.

More information about the Gcc-patches mailing list