This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
- From: "Paolo Bonzini" <bonzini at gnu dot org>
- To: "Kenneth Zadeck" <zadeck at naturalbridge dot com>
- Cc: gcc-bugzilla at gcc dot gnu dot org, Kenneth dot Zadeck at naturalbridge dot com, "Park, Seongbae" <seongbae dot park at gmail dot com>, "Steven Bosscher" <stevenb dot gcc at gmail dot com>, "Vladimir Makarov" <vmakarov at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 2 Jan 2009 15:25:55 +0100
- Subject: Re: [Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
- References: <bug-35805-14137@http.gcc.gnu.org/bugzilla/> <20081229234033.22904.qmail@sourceware.org> <495D61E6.9070406@naturalbridge.com> <495DCD3D.2090609@gnu.org> <495E1FF6.1030908@naturalbridge.com>
> 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