This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bug fix in haifa schedule (fwd)
- To: egcs at cygnus dot com
- Subject: Re: bug fix in haifa schedule (fwd)
- From: Weiwen Liu <liu at hepvms dot physics dot yale dot edu>
- Date: Thu, 25 Sep 1997 21:30:54 -0400 (EDT)
I forgot to send this message to egcs list.
---------- Forwarded message ----------
Date: Thu, 25 Sep 1997 15:00:34 -0400 (EDT)
From: Weiwen Liu <liu@hepunix.physics.yale.edu>
To: law@cygnus.com
Subject: Re: bug fix in haifa schedule
On Thu, 25 Sep 1997, Jeffrey A Law wrote:
> In message <Pine.OSF.3.96.970923185326.12950A-100000@hepunix1.physics.yale.edu>you write:
> > Hi,
> >
> > The patch I sent earlier fixes the problem in the test case but causes
> > problem for other cases. Here is the update of the fix which should
> > be applied against egcs-970917 source.
> Thanks. It's a real bug, and similar to one I've already worked
> on in haifa.
>
> Your patch is incorrect, but your analysis was quite useful.
Why my patch is incorrect?
>
> The fundamental and basic problem is schedule_block and
> compute_forward_dependences aren't processing the same
> group of LOOP/EH notes, which can lead to extra notes.
>
> Due to an intrablock movement of instructions, it is possible for
> compute_forward_dependences to process a LOOP/EH note that is
> skipped by schedule_block. The same thing used to happen in some
> cases when schedule_block used to copy hard parms from hard regs
> to pseudos at the start of the function.
>
> I'm not sure how to fix this instance, but I'm pretty sure your
> patch isn't the right way.
>
> One thought would be to make the scheduler handle basic blocks
> that begin and/or end with NOTEs, then change the get_block_head_tail
> to not skip notes at the start or end of a basic block.
>
> Another would be to disallow certain cross block movements; the
> trick is how to detect insns which can't move because they'd
> expose "bad" notes at the start or end of a block.
>
> Another way would be to remove the saved notes from the first insn
> in a block.
This yields the same result as what my patch did.
For example, let's consider
;Basic block 2
(insn1 ...)
(LOOP_BEG note)
(insn2 ...)
In sched_analyze, this block becomes:
(insn1 ...)
(LOOP_BEG note)
(insn2 + EXPR_LIST) // EXPR_LIST contains a note of LOOP_BEG
After insn1 is moved to basic block 1, block 2 becomes
(LOOP_BEG note)
(insn2 + EXPR_LIST)
You propose to remove EXPR_LIST from insn2, and the result is
(LOOP_BEG note)
(insn2)
My patch results in
(insn2 + EXPR_LIST)
and in schedule_block the EXPR_LIST is restored and we have
(LOOP_BEG note)
(insn2)
These two results are the same.
>
> Jeff
Another question I have is:
Looking at the rtl's generated from my test program before
haifa-schedule, we have a basic block like
(code_label)
(LOOP_BEG note)
(insn1)
(LOOP_BEG note)
(insn2)
sched_analyze generates
(code_label)
(LOOP_BEG note)
(insn1)
(insn2 + EXPR_LIST)
schedule_block moves insn1 to a previous block. I am not quiet sure this
is correct. Haifa should not be able to move insn1 to before code_label
or LOOP_BEG.
It seems to me that intrablock movement in haifa has bugs. Should we have
a flag to disable intrablock movement until we are sure haifa will
function correctly?
One more question, could anyone tell me how a basic block is set up?
There are some notes between basic blocks, which might contains LOOP_BEG.
I am trying to fix some bugs in haifa, and it will save me some time if I
do not need to scan through other source codes beside haifa-sched.c to get
an answer.
Weiwen