Re: RFA: 4.2 reload infrastructure to fix PR target/21623

[Ian Lance Taylor <ian at airs dot com>]

Joern RENNECKE <joern.rennecke@st.com> writes:

> +Define constraints for the reload register and scratch register that
> +contain a single register class.  For input reloads, the reload register
> +is matched against the constraint of operand 0, for output registers,
> +against the iconstraint of operand 1.  If the hook returned NO_REGS, then
> +the original reload register (whose class is @var{reload_class}) is matched
> +against that constraint; otherwise, the intermediate reload register of the
> +class specified by the return value of the hook is matched against that
> +constraint.  The the reload register matches, no further intermediate
> +reister is required; if not, another intermediate register of the class
> +specified by the constraint is allocated.   However, the current
> +implementation only supports one temporary register, i.e. the compiler
> +will currently abort if the returned class is not NO_REGS but doesn't
> +match its constraint.

I think that what you are describing is a positive step forward.

However, I also think that you are keeping the ugliest aspect of the
current interface, which is the above paragraph.  The issue seems more
or less straightforward to me.  We need to move a value in or out of a
register.  For some reason we can not do a direct move.  We need zero
or more intermediate registers.  We need zero or more scratch
registers.  For each intermediate register, we need to determine a
register class (the mode presumably stays the same).  For each scratch
register, we need to specify a mode and a class.

So, how does the hook return this information?  Well, currently it
does so using this complicated dance which you describe in the
paragraph above, in which the class returned by the target is matched
against the class described by the insn to decide whether we need
another register.  Is there any good reason to retain this?

What if:

1) the hook returns the number of intermediate registers required, I
   (where an intermediate register has the property that it will hold
   the value after the instructions are executed)

2) the insn pattern must have >= 2 + I operands (in particular, may
   have only 2 operands, though that would be unusual)

3) operand 0 is the destination

4) operand 1 is the source

5) operands 2 <= op < 2 + I describe the intermediate registers

6) operands >= 2 + I describe the scratch registers

7) all operands >= 2 must use a single register class constraint,
   must use '=', may use '&'

Ian