Re: The secondary reload

[Ian Lance Taylor <iant at google dot com>]

pocmatos@gmail.com (Paulo J. Matos) writes:

> Paul Koning <paul_koning@dell.com> writes:
>
>>> I assume you by 'instruction' here mean a define_insn and not a single
>>> RTL or assembler instruction. 
>>> 
>>> So, assume I have two classes M_REGS and Y_REGS and I cannot move 
>>> between them except if I go through an intermediary in C_REGS. 
>>> Do I need a secondary reload? 
>>
>> Yes
>>> 
>>> I wouldn't expect so cause I could write a rule that has a scratch from
>>> C_REGS. Then I move the value from SOURCE to C_REGS and from C_REGS to
>>> DEST. Have I misunderstood what you said? 
>>>
>
> What about the above case?
> Couldn't you have something like I described above:
> (define_insn "transfer"
>    [
>      (set (match_operand 0 "register_operand" "m")
>           (match_operand 1 "register_operand" "y"))
>      (clobber (match_scratch 2 "c"))
>    ]
>  ""
> {
>    move from 1 to 2;
>    move from 2 to 0;
> })
>
> Why would something like this not work and force you to have a secondary
> reload hook?

First I'll note that in gcc the movMODE insn patterns are special.  They
must be able to handle any simple move.  So you can't use a separate
insn as above to move the instructions.

Second, at reload time you can't generate a new insn which uses a
match_scratch, because reload runs after register allocation and it's
too late to create a new scratch register.  You have to use a secondary
reload to get a scratch register at reload time.  Now, reload does only
require the ability to load and store from memory, so for a lot of code
you can get away without using a secondary reload to transfer a value
from one register class to another.  However, in my experience it is
always possible to write code that uses an unusual typecast to cause gcc
to want to move the value directly from a register in one class to a
register in another class.  And then you need the secondary reload.

Ian