Hi, I'm still working on a private backend on gcc 4.9.2. My processor provides instructions with 2 delay slots. I'm well aware that this feature is very uncommon and not fully tested. Nevertheless I submit the problem and the solution I've found.
The bug is located in the function try_merge_delay_insns(INSN, THREAD) in
reorg.c. In there, gcc " tries to merge insns starting at THREAD which match
exactly the insns in INSN's delay list ".
Suppose INSN is a 'delayed jump' filled with 2 delayed insns :
jmp_if_EQ_delayed .L1 # jump to L1 if condition code indicates equality
mov r1, r2
mov r3, mem(r1++) # move r0 in memory pointed by r6 and post
increment r6
and TARGET is a 'delayed jump if zero' filled with 1 delayed insn :
jmpz_delayed --r7, L2 # decrement r7 and jump L2 if r7 == 0
mov r1, r2
The current implementation of try_merge_delay_insns(INSN, THREAD) will delete
'mov r1,r2' from the delay slot of TARGET because it matches the 'mov r1,r2'
inside INSN delay list. No check verifies that r1 has changed between the 2
'mov r1,r2' insns.
I attached a patch that tries to solve this problem.
Regards,
Selim
try_merge_patch
Description: try_merge_patch
