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 14:44:19 -0600
- Subject: Re: GCC trunk SPEC2000 performance
- Reply-to: law at redhat dot com
In message <3D123660.A20EFB79@moene.indiv.nluug.nl>, Toon Moene writes:
> Jan Hubicka wrote:
>
> > Hmm, obvious fix appears to be the patch attached. I am not at all sure
> > whether it is the sane fix,
>
> > ! if (REG_POINTER (map->x_regno_reg_rtx[regno]))
> ===
> > ! if (REG_P (map->x_regno_reg_rtx[regno])
> > ! && REG_POINTER (map->x_regno_reg_rtx[regno]))
>
> Well, I'd say _no_, it isn't a sane fix. As the name implies, the
> x_regno_reg_rtx[] member of the struct *map is a REGISTER rtx and
> therefore *should* *not* be a MEM (as Janis' excellent rtl flag checking
> code correctly diagnoses).
That's certainly my concern.
> The problem is the MEM rtx in this array. I looked into it and I
> couldn't find where it was filled in incorrectly, but I assume someone
> with better gdb skills than mine would be able to find the culprit.
One quick test to throw out one theory would be to see if this abort
happens before reload, during reload or after reload.
As Graham points out elsewhere, reload can modify a REG and turn it into
a MEM. So if we can call copy_rtx_and_substitute after reload, then we
could have MEMs in the regno_reg_rtx array.
jeff