This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: inv_reg_alloc_order
- To: Bernd Schmidt <bernds at pathia dot cygnus dot co dot uk>
- Subject: Re: Patch: inv_reg_alloc_order
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 28 Nov 1999 03:55:15 -0700
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <Pine.LNX.4.04.9911281035030.7880-100000@pathia.cygnus.co.uk>you w
rite:
>
> 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.
jeff