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: Jan Hubicka <jh at suse dot cz>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>,John Wehle <john at feith dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 16 Apr 2002 12:41:16 +0200
- Subject: Re: remaining libjava/verify_local_live_at_start failures
- References: <20020326141836.A16366@redhat.com> <Pine.BSF.4.30.0204152237510.26513-100000@dair.pair.com>
> 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.
Uhm, perfect explanation. Congratulations and my thanks for solving
the problem.
Honza
>
> brgds, H-P