Re: DFA scheduling bug?

[Vladimir Makarov <vmakarov at redhat dot com>]

Dan Towner wrote:
> 
> Hi all,
> 
> I have encountered a problem with the DFA scheduler, for a 16-bit DSP
> port of gcc, in which an invalid schedule is generated.
> 
> At the end of a function, the expand_epilogue pattern is used to load
> the return address from memory, into a register, and then jump to the
> location in that register. It looks like this, immediately before the
> DFA scheduling pass (in bbro):
> 
> (insn/f 58 57 59 2 (nil) (set (reg:HI 12 R12)
>          (mem:HI (plus:HI (reg/f:HI 13 FP)
>                  (const_int 0 [0x0])) [0 S2 A16])) 15 {movhi} (nil)
>      (nil))
> 
> (jump_insn 59 58 60 2 (nil) (parallel [
>              (return)
>              (use (reg:HI 12 R12))
>          ]) 6 {*fn_return} (insn_list 58 (nil))
>      (expr_list:REG_DEAD (reg:HI 12 R12)
>          (nil)))
> 
> Note that the return address is loaded from a stack location into R12,
> and then the return instructions uses R12. After the DFA scheduling
> pass, this code fragment has been converted into the following:
> 
> (insn/f 58 57 34 2 (nil) (set (reg:HI 12 R12)
>          (mem:HI (plus:HI (reg/f:HI 13 FP)
>                  (const_int 0 [0x0])) [0 S2 A16])) 15 {movhi} (nil)
>      (nil))
> 
> (insn 34 58 59 2 (nil) (use (reg/i:HI 0 R0 [ <result> ])) -1 (insn_list
> 31 (nil))
>      (nil))
> 
> (jump_insn 59 34 60 2 (nil) (parallel [
>              (return)
>              (use (reg:HI 12 R12))
>          ]) 6 {*fn_return} (insn_list:REG_DEP_ANTI 58
> (insn_list:REG_DEP_ANTI 31 (insn_list:REG_DEP_ANTI 34 (nil))))
>      (expr_list:REG_DEAD (reg:HI 12 R12)
>          (nil)))
> 
> And the instructions have been scheduled as:
> 
> ;;        0--> 58   R12=[FP+0x0]                       :slot1,nothing
> ;;        0--> 34   use R0                             :nothing
> ;;        0--> 59   {return;use R12;}                  :slot2
> 
> It appears that the use of the register R12, and the loading from
> memory into that register are being treated as operations which can
> occur in parallel - hence the antidependency that has appeared between
> the instructions. This used to work correctly, but has come about
> after upgrading my code base to gcc 3.4 mainline (from gcc 3.2
> release).
> 
> Any ideas what might be going wrong?
> 

It is probably one of my patches.  Could you sent me dump files before
the insn scheduling and after that using -fsched-verbose=5.  I'll look
at that and try to fix it.

Vlad