This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
DFA scheduling bug?
- From: Dan Towner <dant at picochip dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 25 Mar 2003 16:54:10 +0000
- Subject: DFA scheduling bug?
- Organization: picoChip Designs Ltd.
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