Ian Lance Taylor writes:
>
> The TARGET_SECONDARY_RELOAD hook should set sri->icode to some value if
> there is a specific insn pattern which will do the actual secondary
> reload.
>
> A good example for complex secondary reloads is sh_secondary_reload in
> config/sh/sh.c.
>
Thanks Ian!
--
PMa
pocma...@gmail.com (Paulo J. Matos) writes:
> However, there's a specific secondary reload question still bothering me:
> - I have seen cases where secondary reload is called and sri->icode !=
> CODE_FOR_nothing. In which cases does this happen and should I touch it if
> the reload required no se
additional register
was necessary.
It's fairly complex and a source of numerous questions from people
maintaining their own ports. Even those of us who have done significant
port work forget cases that need to be handled by the secondary reload
mechanisms. I believe most ports have
m a register in one class to a
> register in another class. And then you need the secondary reload.
>
> Ian
>
--
PMatos
Jeff Law writes:
> 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.
Yes, I think you're right. It seems to be a powerful tool that I have
b
r 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
On 12/07/10 08:30, Paulo J. Matos wrote:
Paul Koning 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
Paul Koning writes:
>
> I don't know enough to answer that. But I do know that the secondary
> reload stuff works great, and is reasonably well documented, and it
> takes only a few lines to put into effect. Why not give it a try?
Thanks for your input Paul.
Actually the p
"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
Paul Koning 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 rel
On Dec 7, 2010, at 9:51 AM, Paulo J. Matos wrote:
> Ian Lance Taylor writes:
>
>> [snip]
>> after register allocation. After the second split, no output template
>> should still be "#".
>>
>
> What do you mean by your last sentence? It somehow makes me think that
> the splits work at some pr
Ian Lance Taylor writes:
> [snip]
> after register allocation. After the second split, no output template
> should still be "#".
>
What do you mean by your last sentence? It somehow makes me think that
the splits work at some preprocessing level replacing/rewriting the output
template of instru
ster allocation. After the second split, no output template
should still be "#".
> During reload we have TARGET_SECONDARY_RELOAD being massively called
> with all kinds of expressions and reload modes. One interesting thing I
> noticed is that in gcc4.3 i386 has no TARGET_SECON
ng I
noticed is that in gcc4.3 i386 has no TARGET_SECONDARY_RELOAD defined
and it made me wonder if the secondary reload is really something of a
hack that is best avoided by writing clearer/better backend rules or if
there are specific cases which it _has_ to be defined for reload to
work.
Cheers,
--
PMatos
14 matches
Mail list logo
