Re: preprocess_constraints, reg-stack.c and register classes

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 10 Mar 2003, Christian Ehrhardt wrote:

> preprocess_constraints calculates (among other things) the
> register class of each operand in each alternative. However,
> if an operand's constraint is just a number (i.e. it must match
> another operand) the register class is uninitialized (NO_REGS).

NO_REGS is not uninitialized.  If one is really interested in the class
for a matching constraint depends on the actual use case.  After all, a
matching constraint has not only a class of possible objects, but instead
it must be equal to another operand.  So for some uses it arguably is
wrong to let it have a class.

> The correct value would be the register class of the matched operand.
>
> There are currently two users of this field:
> * reg-stack.c just uses the class field without ever considering
>   if it was initialized. I don't know if i387 instructions just don't
>   use matched operands or if reg-stack.c is buggy.

reg-stack.c only calls preprocess_constraints() and handled recog_op_alt
for asm insns (i.e. user specified asm insns), not for anything created by
GCC itself.  And for asm insns there are certain rules to obey when they
deal with STACK_REGS (see the top of reg-stack.c).

> * regrename.c calculates the proper register class before looking at
>   the class field.
>
> My question is: Wouldn't it be a good idea if preprocess_constraints
> would calculate the proper regclass?

Hmm, maybe.  Users interested if it's a matching constraint anyway need to
use the "matches" member and can't rely on the "class" member being
NO_REGS, as that can also stand for really no regs ;-)

Do you see an actual failure somewhere, or do you just want to clean it up
(which might be worthwhile in itself)?


Ciao,
Michael.