Hi Paolo, thanks for the tip.
I tried it and things look different now, but I still didn't achieve
the desired efficiency. Now after subreg lowering the code looks like:
(insn 6 29 7 (parallel [
(set (subreg:SI (reg/v:DI 133 [ tmp ]) 0)
(unspec:SI [ (reg/f:SI 135)] 12036))
(set (subreg:SI (reg/v:DI 133 [ tmp ]) 4)
(unspec:SI [(reg/f:SI 135)] 12037))
]))
(insn 7 6 11 (set (reg:SI 139)
(subreg:SI (reg/v:DI 133 [ tmp ]) 4)) )
(insn 11 7 12(set (reg:SI 138 [ tmp ]
(subreg:SI (reg/v:DI 133 [ tmp ]) 0)) )
The copy operations are still there, and, unfortunately, they are not removed
in later stages.
I am now trying to catch this construct with peephole2 and
do the removal there. I don't like this solution though, as the scheduler might
reorder insns. I wonder if splitter might help in this, as it runs
before the scheduler?
In your case, were the moves generated at all ? If yes, at what stage were they
removed?
I also think, if I want the regs to be non-consecutive, the insn with
DI as an operand
shouldn't appear in the final stages, because the DI operand would
require consecutive regs. Therefore I try to substitute originally
expanded insn in the peephole2 (or in split?) with a similar one with
two SI destination operands instead of
DI subregs. Does it sound logical or I am wrong in my assumption ?
Dmitry
Ps. Ian, i use version 4.3.0
On 2/7/08, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > In the response of Paolo I also don't understand how the DI pseudo could be
> > mapped on two consecutive SI regs. I think gcc always will map a multiword
> > pseudo on consecutive word-size regs. Am I wrong here ?
>
> Oops, I forgot a part. In the RTL description don't write
>
> [(set (match_operand:DI 0 "register_operand")
> (unspec [...] SUPER_LD32))]
>
> but
>
> [(set (subreg:SI (match_operand:DI 0 "register_operand") 0)
> (unspec [...] SUPER_LD32_LO))
> (set (subreg:SI (match_operand:DI 0 "register_operand") 4)
> (unspec [...] SUPER_LD32_HI))]
>
> Paolo
>
