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]

try_merge_delay_insn with delay list > 1


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


Attachment: try_merge_patch
Description: try_merge_patch


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