This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: remaining libjava/verify_local_live_at_start failures
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, John Wehle <john at feith dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 15 Apr 2002 22:46:39 -0400 (EDT)
- Subject: Re: remaining libjava/verify_local_live_at_start failures
On Tue, 26 Mar 2002, Richard Henderson wrote:
> On Tue, Mar 26, 2002 at 03:18:02PM +0100, Jan Hubicka wrote:
> > No, the answer is valid, but the killing of dead code invalidates it.
> > Uhm, perhaps I see what is nasty. In case calculate_global_regs_live is
> > able to recognize deadness of register set and do not mark live it's arguments
> > assuming that the set will be killed later this works.
> > The testcase I had in my hands killed dead memory store that goes using
> > different channels. Perhaps only the dead memory store removal code is broken
> > and needs reitration (or modification of claculate_global_*)
>
> If *anything* within a single basic block gets different answers
> when run multiple times, something is wrong.
I've been looking at this. The problem on MMIX with
g77.f-torture/compile/970915-0.f -Os that Jan's trying to fix
(thanks!) is that local basic block processing actually finds
out that a pseudo isn't alive, and sanity checking fails because
global basic block processing was supposed to be complete.
This isn't supposed to happen, but is due to the capping on
MAX_MEM_SET_LIST_LEN for "dead writes". When some of the dead
writes are removed others fit within that limit. See next patch
for more on this.
brgds, H-P