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.
