On 12/07/10 08:30, Paulo J. Matos wrote:
Paul Koning<paul_kon...@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
