This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 19 Jan 2015 22:29:54 +0000
- Subject: [Bug target/63347] m68k misoptimisation with -fschedule-insns
- Auto-submitted: auto-generated
- References: <bug-63347-4 at http dot gcc dot gnu dot org/bugzilla/>
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.