[Bug target/63347] [5 regression] m68k misoptimisation with -fschedule-insns

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
Right.  I know we've got the SCHED_GROUP_P handling in prune_ready_list, but
it's not sufficient.

This is a regression with the trunk.

Take the code from c#0 and run it through a m68k-elf compiler with -O1
-fschedule-insns -mcpu=5208.

Prior to scheduling we have:
(insn 25 24 26 3 (set (cc0)
        (compare (reg/v:SI 32 [ haddr ]) 
            (const_int 0 [0]))) j.c:5 4 {*tstsi_internal_68020_cf}
     (expr_list:REG_DEAD (reg/v:SI 32 [ haddr ])
        (nil)))
(insn 26 25 27 3 (set (reg:QI 54)
        (eq:QI (cc0)
            (const_int 0 [0]))) j.c:5 364 {*m68k.md:5773}
     (nil)) 
(insn 27 26 28 3 (set (reg:SI 53)
        (sign_extend:SI (reg:QI 54))) j.c:5 82 {*68k_extendqisi2}
     (expr_list:REG_DEAD (reg:QI 54)
        (nil)))


After scheduling we get:

(insn 25 24 30 3 (set (cc0)
        (compare (reg/v:SI 32 [ haddr ])
            (const_int 0 [0]))) j.c:5 4 {*tstsi_internal_68020_cf}
     (expr_list:REG_DEAD (reg/v:SI 32 [ haddr ])
        (nil))) 
(insn 30 25 26 3 (set (mem:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0  S4 A16])
        (const_int 10 [0xa])) j.c:17 33 {pushexthisi_const}
     (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
        (nil)))
(insn 26 30 27 3 (set (reg:QI 54) 
        (eq:QI (cc0)
            (const_int 0 [0]))) j.c:5 364 {*m68k.md:5773}
     (nil))
(insn 27 26 28 3 (set (reg:SI 53)
        (sign_extend:SI (reg:QI 54))) j.c:5 82 {*68k_extendqisi2}
     (expr_list:REG_DEAD (reg:QI 54)
        (nil))) 


Which is obviously wrong with the insertion of insn 30 between the cc-setter
and user.

When I looked at this a month ago my conclusion was that prior to your changes
when we saw the SCHED_GROUP_P flag set, we'd just advance the cycle counter the
appropriate number of cycles to ensure the insn with SCHED_GROUP_P was ready. 

With your changes we schedule the setter, but the result isn't ready for 2
cycles, so we queue the user.  On the next cycle, insn 30 has become ready and
it fires while the user (insn 26) is still queued.  Then 26 issues and we've
got incorrect code.

This history mentions some problem with the old code and the tic6x, but not
enough details for me to know if any changes I might suggest to fix this bug
would in turn mess up the tic6x.