The secondary reload
Jeff Law
law@redhat.com
Tue Dec 7 16:01:00 GMT 2010
On 12/07/10 08:30, Paulo J. Matos wrote:
> 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?
That's not going to work for a variety of reasons. The most obvious of
which is when is that pattern ever going to match any generated insn?
And even if it did, the constraints aren't applied until reload, so
every reg->reg copy would need to have a scratch register, which
effectively boils down to reserving a register.
You can often avoid secondary reloads by removing a register from the
set of registers available to use during allocation and reserving it for
these special cases; that practice is generally frowned upon as it
penalizes the majority of code which doesn't need secondary reloads for
the oddball cases that do need secondary reloads. It also fails in
cases where you need multiple secondary reload registers. And yes,
there are cases where multiple secondary reload registers are needed,
along with secondary memory.
You're better off taking the time to understand how secondary reloads
work. In addition to your port working better, the knowledge you gain
will help you with other maintenance burdens with your port.
jeff
More information about the Gcc
mailing list