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

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Bernd, need your input on the best direction here...

This BZ is caused by mis-handling of SCHED_GROUP_P in some scheduler work from
a few years ago (meaning it's probably a 4.8 and 4.9 regression as well).

The offending commit is :

Author: bernds <bernds@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Apr 1 17:48:35 2011 +0000

        * haifa-sched.c (prune_ready_list): New function, broken out of
        schedule_block.
        (schedule_block): Use it.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171845
138bc75d-0d04-0410-961f-82ee72b054a4


As can be seen in this BZ, it can cause incorrect code anywhere we use
SCHED_GROUP_P to keep insns together for correctness.  It can cause
missed-optimizations for things like insn fusion.

The old code would just advance the cycle counter forward the appropriate
number of cycles when it saw a SCHED_GROUP_P insn.   I can hack something
together to have a similar effect here, but I'm unsure if it would break the
tic6x.