This is the mail archive of the
mailing list for the GCC project.
Re: Scheduling fix (fixes gcc.c-torture/execute/980506-1.c on ppc)
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Subject: Re: Scheduling fix (fixes gcc.c-torture/execute/980506-1.c on ppc)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 26 Aug 1998 00:42:49 -0600
- cc: Geoff Keating <geoffk at ozemail dot com dot au>, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
> >Now, basic block 2 has two exits. One exit goes back to basic block
> >1. The other goes off the edge of the procedure. Unfortunately,
> >haifa only notices the first one, because the second exit doesn't go
> >to any basic block, and thinks basic block 2 has only one exit; so the
> >branch must be taken with 100% probability:
Right. But this is a total red herring. The problem is/was elsewhere.
> Tue Aug 18 10:32:11 1998 Jeffrey A Law (firstname.lastname@example.org)
> * haifa-sched.c (sched_analyze): Put all JUMP_INSNs on the last
> pending memory flush list.
> This patch alone fixed 980506-1.c for me and others. Doesn't it fix all
> possible cases?
Catherine's patch should have fixed 980506-1.c completely.
The core problem was we should not be moving memory references past
jump instructions at all. It would be nice one day to fix up the
code for speculative load/store scheduling though since several new
architectures have some kind of speculative load/store support.