This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

DFA scheduling bug?


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?

thanks,

dan.

=============================================================================
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
dant at picochip dot com
07786 702589




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]