Unable to remove pipeline stalls

Ian Lance Taylor iant@google.com
Thu Jul 19 04:46:00 GMT 2012


On Wed, Jul 18, 2012 at 9:03 PM, Deepti Sharma
<deepti.gccretarget@gmail.com> wrote:
>
> As we see above, the scheduler is not able to reschedule the instructions to
> remove stalls.
> I understand that the removal of stalls is performed by scheduler-pass1
> (sched1).
> However, since the scheduler1 is receiving the instruction as a single
> instruction "[r62++]=[r63++]",
> it does not know that it is later broken down into two MOVE operations.

Yes, it would be better if it could know that.

> I don't have a define_split pattern for MOVE. I have a define_expand, like
> below:


> (define_insn "*movsi"
>   [(set (match_operand:SI 0 "nonimmediate_operand" "=z,z,x,x, xz,co1 ")
>         (match_operand:SI 1 "general_operand"      " z,x,z,x, co1,xz "))]
>   ""
>   "@
>   MOV %0, %1
>   MOVE %0, %1
>   MOVE %0, %1
>   MOVE %0, %1
>   MOVE %0, %1
>   MOVE %0, %1"
>   [(set_attr "ATTR1" "mem1, mem1, mem1, mem1, mem1, mem1")
>    (set_attr "ATTR2" "none, op1, op1, op1, op2, op1")])

This approach implies that you are relying on reload to see that there
is no memory-to-memory move, and to allocate a register to do the load
and store.  It would be better to handle this in the define_expand.
Most targets do something like
    if (!register_operand (operands[0], SImode) && !register_operand
(operands[1], SImode))
      operands[1] = force_reg (operands[1], SImode);

Ian



More information about the Gcc-help mailing list