This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: register renaming causes many ARM testsuite failures
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: register renaming causes many ARM testsuite failures
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Thu, 04 Jan 2001 15:24:09 +0000
- Cc: Philip Blundell <philb at gnu dot org>, Bernd Schmidt <bernds at redhat dot com>, gcc-bugs at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> On Wed, Jan 03, 2001 at 07:57:51PM +0000, Philip Blundell wrote:
> > >The function build_def_use uses constraints to determine which registers can
> > >be used for renaming. The relevant bit of code is this:
> >
> > If I'm reading that right, it just notes which class an operand is in so
> > that it can later choose another register in the same class. The problem
> > at hand here is that the actual registers in use, not just their classes,
> > matter in an ldmsi insn. Am I missing something about the code you quoted?
>
> He's right Bernd. We're going to need some way to squash renaming
> in this case. Probably through a new constraint token indicating
> that we shouldn't consider this operand for renaming.
>
>
> r~
Before you go into to much re-engineering of this, I think I can fix the
ARM back-end for this case. The problem here is that we have an operand
with the predicate:
(match_operand:SI n "s_register_operand" "r")
but we pre-allocate a specific hard register to this, and don't expect it
to change. The work-around is to change this operand to match the hard
reg we have pre-allocated, since there are other places that also expect
this to remain unchanged.
I'm currently bootstrapping a patch which does exactly that.
R.