This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
- From: "bonzini at gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Jan 2009 14:26:44 -0000
- Subject: [Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
- References: <bug-35805-14137@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from bonzini at gnu dot org 2009-01-02 14:26 -------
Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
> I think so. The global changed flag allows it to delete the case:
>
> loop:
> ... <- x // This is dead.
> x- <- ...
> go to loop
>
> it just is not going to get rid of it if there is is no kill of x inside
> the loop.
I just don't think it's acceptable to load each and every "fast DCE"
with the burden of a full df solution. We need to find a way to limit
this to the cases when it is needed, or at least not to be too
conservative in ascertaining *when* it is needed.
Hence my first and foremost question is: does it happen that the
solution is wrong and global_changed never became true?
If the answer is "definitely no", then an alternative preferrable
patch would be to move the code you added to df-problems.c into dce.c,
so that the full analysis (including rebuilding the bitmaps and
iterating possibly many times) is not run if it was to yield the same
answer that was before in the bitmaps.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805