Issue with delay slot scheduling?

Issue with delay slot scheduling?

[Mohamed Shafi]

Hi,

I am doing a private port in GCC 4.5.1. For the my target i see some
strange behavior in delay slot scheduling. For my target the
instruction in the delay slots gets executed irrespective of whether
the branch is taken or not. I have generated the following code after
commenting out the call to 'relax_delay_slots' in the function
'dbr_schedule'.

RTL:

(insn 97 42 51 del1.c:19 (sequence [
            (jump_insn 61 42 38 del1.c:19 (set (pc)
                    (if_then_else (ne (reg:CCF 34 CC)
                            (const_int 0 [0x0]))
                        (label_ref:PQI 86)
                        (pc))) 56 {conditional_branch}
(expr_list:REG_BR_PRED (const_int 5 [0x5])
                    (expr_list:REG_DEAD (reg:CCF 34 CC)
                        (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
                            (nil))))
             -> 86)
            (insn 38 61 43 (set (mem/s/j:QI (reg/f:PQI 28 a0 [orig:62
D.1955 ] [62]) [0 bytes S1 A32])
                    (reg:QI 1 g1 [orig:65 D.1938 ] [65])) 7 {movqi_op} (nil))
            (insn 43 38 51 (set (reg:QI 1 g1 [75])
                    (ior:QI (reg:QI 1 g1 [orig:65 D.1938 ] [65])
                        (reg:QI 3 g3 [77]))) 31 {iorqi3}
(expr_list:REG_EQUAL (ior:QI (reg:QI 1 g1 [orig:65 D.1938 ] [65])
                        (const_int 128 [0x80]))
                    (nil)))
        ]) -1 (nil))

(code_label 51 97 52 1 "" [2 uses])

(note 52 51 73 [bb 4] NOTE_INSN_BASIC_BLOCK)

(jump_insn 73 52 72 (return) 72 {return_rts} (expr_list:REG_BR_PRED
(const_int 12 [0xc])
        (nil)))

(barrier 72 73 86)

(code_label 86 72 41 5 "" [1 uses])

(note 41 86 45 [bb 5] NOTE_INSN_BASIC_BLOCK)

(insn 45 41 44 del1.c:20 (set (reg:QI 2 g2 [orig:68 ivtmp.7 ] [68])
        (plus:QI (reg:QI 2 g2 [orig:68 ivtmp.7 ] [68])
            (const_int 1 [0x1]))) 13 {addqi3} (nil))

(insn 44 45 101 del1.c:20 (set (mem/s/j:QI (reg/f:PQI 28 a0 [orig:62
D.1955 ] [62]) [0 bytes S1 A32])
        (reg:QI 1 g1 [75])) 7 {movqi_op} (expr_list:REG_DEAD
(reg/f:PQI 28 a0 [orig:62 D.1955 ] [62])
        (expr_list:REG_DEAD (reg:QI 1 g1 [75])
            (nil))))

(code_label 101 44 79 7 "" [1 uses])


Corresponding code:

        jmp.ne  .L5;
        st      [a0], g1;             (INSN 38)
        or      g1, g1, g3;          (INSN 43)
.L1:
        rts;
        nop;
        nop;
.L5:
        add   g2, g2, 1;           (INSN 45)
        st      [a0], g1;            (INSN 44)  -> deleted
.L7:



You can see that INSN 44 and INSN 38 are identical. In
'relax_delay_slots' while processing INSN 97, the second call to
'try_merge_delay_insns' deletes the INSN 44 because of which
unexpected result is generated.

      /* If we own the thread opposite the way this insn branches, see if we
	 can merge its delay slots with following insns.  */
      if (INSN_FROM_TARGET_P (XVECEXP (pat, 0, 1))
	  && own_thread_p (NEXT_INSN (insn), 0, 1))
	try_merge_delay_insns (insn, next);
      else if (! INSN_FROM_TARGET_P (XVECEXP (pat, 0, 1))
	       && own_thread_p (target_label, target_label, 0))
	try_merge_delay_insns (insn, next_active_insn (target_label));

Deleting the INSN 44 would have been proper if the 2nd delay slot insn
had not modified G1. But looking at the comments from the function
'try_merge_delay_insns'

/* Try merging insns starting at THREAD which match exactly the insns in
   INSN's delay list.

   If all insns were matched and the insn was previously annulling, the
   annul bit will be cleared.

   For each insn that is merged, if the branch is or will be non-annulling,
   we delete the merged insn.  */

I think REGOUT dependency of g1 between instructions 38 and 43 in the
delay slot is not being considered by 'try_merge_delay_insns'.

Is this a bug?

Regards,
Shafi

Re: Issue with delay slot scheduling?

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/11 08:46, Mohamed Shafi wrote:
> Hi,
> 
> I am doing a private port in GCC 4.5.1. For the my target i see some 
> strange behavior in delay slot scheduling. For my target the 
> instruction in the delay slots gets executed irrespective of whether 
> the branch is taken or not. I have generated the following code
> after commenting out the call to 'relax_delay_slots' in the function 
> 'dbr_schedule'.
[ ... ]
It looks like you have found a bug.  While reorg.c is supposed to work
with targets that have multiple delay slots, it's not something that has
been extensively tested.

>> 
> I think REGOUT dependency of g1 between instructions 38 and 43 in
> the delay slot is not being considered by 'try_merge_delay_insns'.
You're probably correct.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOZjpZAAoJEBRtltQi2kC7Hq4H/1m6RaLUP+3RXCLT8zZgZ7YN
i/8EmgGrjsJevsjWZEaIVW0yzjMwtQU0bwTVEj9aYEKFh4s9xAWWZfWYxy40StZs
8dp5cU9k672CNecI+tYNXFlZLqDhJ/YImwW/L9KvppeSo1VCXjjzLbVoJ2CrRBM4
eJw+PEk6yWwbz2bXvOfJr/1ziEvjGddLzet6eICv5ypqO+jKzC+FOaQl/I3sJCWO
axforjfSUlthYGwYlRgHlJgrWfgRIG/AhAqhkhOqSWzcIdEzy2XFuL8ez6mOe7rW
qeyeZwClTpPuCtBZ7vkfQ0+LZHa5pRZHXeO9GK+OGHFzUm8kS5eaAzCIAZP1J7E=
=bfxg
-----END PGP SIGNATURE-----

Re: Issue with delay slot scheduling?

[Eric Botcazou]

> I am doing a private port in GCC 4.5.1. For the my target i see some
> strange behavior in delay slot scheduling. For my target the
> instruction in the delay slots gets executed irrespective of whether
> the branch is taken or not. 

Early 4.5.x releases have known bugs in this area.  You'd need to upgrade to 
4.5.3 at least (or use the SVN 4.5 branch).  That being said, targets with 
multiple delay slots are indeed relatively untested.

-- 
Eric Botcazou

Re: Issue with delay slot scheduling?

[Mohamed Shafi]

On 6 September 2011 20:50, Jeff Law <law@redhat.com> wrote:
>
> On 09/06/11 08:46, Mohamed Shafi wrote:
>> Hi,
>>
>> I am doing a private port in GCC 4.5.1. For the my target i see some
>> strange behavior in delay slot scheduling. For my target the
>> instruction in the delay slots gets executed irrespective of whether
>> the branch is taken or not. I have generated the following code
>> after commenting out the call to 'relax_delay_slots' in the function
>> 'dbr_schedule'.
> [ ... ]
> It looks like you have found a bug.  While reorg.c is supposed to work
> with targets that have multiple delay slots, it's not something that has
> been extensively tested.
>
>>>
>> I think REGOUT dependency of g1 between instructions 38 and 43 in
>> the delay slot is not being considered by 'try_merge_delay_insns'.
> You're probably correct.
>
> Jeff

How do raise a bug report, mine being a private target?

Regards,
Shafi

Re: Issue with delay slot scheduling?

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/11 23:08, Mohamed Shafi wrote:
> On 6 September 2011 20:50, Jeff Law <law@redhat.com> wrote:
>> 
>> On 09/06/11 08:46, Mohamed Shafi wrote:
>>> Hi,
>>> 
>>> I am doing a private port in GCC 4.5.1. For the my target i see
>>> some strange behavior in delay slot scheduling. For my target
>>> the instruction in the delay slots gets executed irrespective
>>> of whether the branch is taken or not. I have generated the
>>> following code after commenting out the call to
>>> 'relax_delay_slots' in the function 'dbr_schedule'.
>> [ ... ] It looks like you have found a bug.  While reorg.c is
>> supposed to work with targets that have multiple delay slots,
>> it's not something that has been extensively tested.
>> 
>>>> 
>>> I think REGOUT dependency of g1 between instructions 38 and 43
>>> in the delay slot is not being considered by
>>> 'try_merge_delay_insns'.
>> You're probably correct.
>> 
>> Jeff
> 
> How do raise a bug report, mine being a private target?

I think you provided a reasonably good description of the problem;
that should be enough given you don't have a public target.  Obviously
you're in the best position to develop & test a fix.  I'm willing to
review it if you do so as I know reorg.c reasonably well.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOb5psAAoJEBRtltQi2kC7MYsH/As8qpHe/IG03Q6Ya2A9VePZ
cS3qrxlVfMOEPrM8D2PbAP6R7khVsC4aoK8nDzXxeGc1K4ljKqKOfHX491eeM3GC
7AdZ7ypYgHLI0dYbTO5s1IXyrkf3ak6DRcgeh+/Dk7DOJu42LSqcUrkh7eOl782V
t7meHHdosxwZMRSxsmk0K/Su+cEnD2LQ5a/d/lNbsRha7nfKrXvnIBZlWWlHmM+u
q7AZQuivEbL4qq2tf43E+WNTwbsf7ZDDwDsszM0YyQ6k7jQBxnfm7IrGX2E61Acm
F17YJ9Bu7hE0m1qRtgDCSk9ppsX8JN+KvD3qAXgo4z5v0/9iaVc/RWjl5Dh11BY=
=aBl0
-----END PGP SIGNATURE-----