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: Geoff Keating <geoffk at ozemail dot com dot au>
- Subject: Re: Scheduling fix (fixes gcc.c-torture/execute/980506-1.c on ppc)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 30 Aug 1998 17:13:26 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199808250324.NAA13633@geoffk.wattle.id.au>you write:
> For the test case, the branch is actually 0% probability, and haifa
> then mis-schedules the procedure.
> If the fix below is not acceptable, then you must go through
> haifa-sched.c and fix every place where it examines the flow graph
> (that is, everywhere in haifa-sched.c) to allow for blocks like block
> 2 in the above. The immediate problem is in compute_dom_prob_ps.
As I mentioned separately, the real fix for this bug was elsewhere.
However, that does not mean we should not try to fix this particular
If you look at the debugging dumps, you'll find that flow does know
that the last block reaches the exit. This implies that haifa is
the problem, not the cfg provided by flow:
Breakpoint 4, find_rgns (s_preds=0xbffff598, s_succs=0xbffff58c,
num_preds=0xbffff580, num_succs=0xbffff574, dom=0x82add90)
1475 char no_loops = 1;
(gdb) p dump_bb_data (asm_out_file, s_preds, s_succs)
BB 0, start 4, end 9
BB 1, start 11, end 14
BB 2, start 15, end 18
preds: 1 0
succs: exit 1
All the necessary information is in the cfg computed by flow; haifa
just isn't using it properly. So if we're going to fix the branch
probabilities, we need to fix haifa, not flow.