This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC trunk SPEC2000 performance
- From: law at redhat dot com
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Cc: Jan Hubicka <jh at suse dot cz>, Andreas Jaeger <aj at suse dot de>, Diego Novillo <dnovillo at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 20 Jun 2002 15:26:29 -0600
- Subject: Re: GCC trunk SPEC2000 performance
- Reply-to: law at redhat dot com
In message <3D124416.5559DB3E@moene.indiv.nluug.nl>, Toon Moene writes:
> Breakpoint 1, copy_rtx_and_substitute (orig=0x405856b0, map=0x85c2718,
> for_lhs=0) at ../../combined/gcc/integrate.c:2065
> 2065 if (REG_POINTER (map->x_regno_reg_rtx[regno]))
> (gdb) p reload_completed
> $1 = 0
> (gdb) p reload_in_progress
> $2 = 0
>
> Nice try, but no cigar :-)
OK. One theory gone.
The other possibility raised by David is that some phase of RTL generation
can turn a REG into a MEM (perhaps ADDRESSOF elimination?)
Looking at function.c I see three lines which look like:
PUT_CODE (reg, MEM);
They appear in put_reg_into_stack, gen_mem_addressof and put_var_into_stack.
If you could put a conditional breakpoint on each of those and see if
they trigger, that would tell us beyond a reasonable doubt that MEMs
can/should appear in the register array.
I'd do this by first running without the breakpoint set. When you get the
abort walk up the call chain until you're in copy_rtx_and_substitute
(ie the location where we checked REG_POINTER on the MEM). print "regno".
Then install your conditional breakpoints with the following condition
reg->fld[0].rtint == <value of regno from above>
Re-run and see if any of them trigger.
jeff