This is the mail archive of the
mailing list for the GCC project.
Re: haifa-sched: Fix problems with cc0 in prune_ready_list
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Apr 2012 10:37:37 -0400
- Subject: Re: haifa-sched: Fix problems with cc0 in prune_ready_list
- References: <4F328E64.email@example.com> <4F35698D.firstname.lastname@example.org> <4F859044.email@example.com>
On 04/11/2012 10:08 AM, Bernd Schmidt wrote:
On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
What a coincidence :) Yesterday I found the same bug on m68k on lra
branch and just started to work on it.
On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
Ok. Thanks, Bernd.
We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lead to a random insn being scheduled between a cc0
setter and user. The patch below fixes it, OK? (Bootstrapped& tested
It turns out that the previous fix was insufficient. If a cc0 user and
another insn are on the ready list, it can happen that the cc0 user is
delayed for longer than the other insn, and we will reenter
prune_ready_list with a new ready insn but with the cc0 user still
queued for later. In that case we'll do the wrong thing.
The following patch reworks the function to take care of this problem.
Bootstrapped and tested on i686-linux, and also tested with a m68k
multilib on our internal compiler (4.6 based but with scheduler patches
from 4.7). Ok?
I assume this should also go into 4.7 eventually.Yes. It is a serious bug for cc0 targets.