This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bug fix in haifa schedule (fwd)


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]