HAIFA scheduler bug?

Gary Thomas g.thomas@opengroup.org
Wed Mar 25 21:57:00 GMT 1998


On 25-Mar-98 Jim Wilson wrote:
> The problem here is that jump.c is using the REG_DEAD notes to decide what
> instructions can be deleted when it makes a change, but REG_DEAD notes are
> not
> valid after reload.  This causes jump to mistakenly delete some instructions
> that are still needed.
> 
> This invalid REG_DEAD note came from a scheduling change that haifa-sched
> made.
> It reversed the order of two instructions, both using the same pseudo, where
> the second one had a REG_DEAD note.  When jump deleted the first insn with
> the REG_DEAD note, it thought it could also delete the insn storing into the
> pseudo, but this is not correct.
> 
> I think the problem has always been there, and that we were just lucky that
> we haven't run into it more often.
> 
> The example doesn't fail with the current sources because we get slightly
> different RTL (due I think to reload changes), and the code in jump.c in
> delete_computation has a == rtl test which fails in this case.  The bug is
> still there though.
> 
> Perhaps we should just add a new pass before the second jump pass to
> recompute
> the REG_DEAD notes?
> 
> Jim

I'm glad that you understand this bug and maybe even have a solution
in mind.  Is this new pass something that can be added simply?  Do
you think we can find a way to get it into the release branch?

If you wanted to point me in the right direction(s), I could see if I
can make the changes.

Thanks for your time,

------------------------------------------------------------------------
Gary Thomas                              |
The Open Group / Research Institute      | "Fine wine is a necessity of
2 Avenue de Vignate                      |        life for me"
38610 Gieres - FRANCE                    |
+33 4 76 63 48 74                        |      Thomas Jefferson
email: g.thomas@opengroup.org            |
< http://www.opengroup.org/~gdt >          |
   ... opinions expressed here are mine  |
       and no one else would claim them! |
------------------------------------------------------------------------





More information about the Gcc-bugs mailing list