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: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Graham Stott <graham dot stott at btinternet dot com>, Toon Moene <toon at moene dot indiv dot nluug dot nl>, Andreas Jaeger <aj at suse dot de>, Jan Hubicka <jh at suse dot cz>, Diego Novillo <dnovillo at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Jun 2002 14:46:58 -0600
- Subject: Re: GCC trunk SPEC2000 performance
- Reply-to: law at redhat dot com
In message <200206202029.QAA24412@makai.watson.ibm.com>, David Edelsohn writes:
> >>>>> Graham Stott writes:
>
> Graham> That all depends if a MEM rtx should ever appear in x_regno_reg_rtx[
> ]
>
> Graham> I can't tell for sure because there's no comment describing this fie
> ld
> Graham> in integrate.h and a quick grep is not conclusive most of the uses I
> Graham> examined implied it was always a REG rtx but in a few cases there is
> Graham> code such as
>
> Graham> if (GET_CODE (regno_reg_rtx[regno]) != REG)
>
> Graham> which tends to imply it might sometimes not be a REG rtx.
>
> reload1.c has the comment:
>
> /* If the reg got changed to a MEM at rtl-generation time,
> ignore it. */
> if (GET_CODE (regno_reg_rtx[i]) != REG)
> return;
>
> which strongly implies that the array can contain MEMs created at RTL
> generation, so assuming that the array only contains REGs is incorrect.
Quite possibly. Though do you see why nobody's reviewed the patch -- Jan
didn't provide any of this kind of technical information which is crucial
to knowing if his patch is correct or not.
And even if we have now decided that MEMs can appear in the reg array, then
we need to have that documented in comments as it's certainly counterintuitive.
jeff