This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Sharing hard registers
- From: law at redhat dot com
- To: "Eric Christopher" <echristo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Thu, 13 Jun 2002 16:27:26 -0600
- Subject: Re: Sharing hard registers
- Reply-to: law at redhat dot com
In message <200206132203.g5DM3lv24315@potter.sfbay.redhat.com>, "Eric Christoph
er" writes:
> On Thu, 13 Jun 2002 13:27:39 -0700, law wrote:
>
>
> > It may be necessary to back out the last patch which makes gen_rtx_REG
> > share hard registers in some circumstances.
> >
> > I've run into a problem in at least the rs6000 port which assumes hard
> > registers are never shared. I'm planning to fix the rs6000, but we need
> > to keep an eye out for problems -- it won't take more than one or two to
> > make me want to revert that part of the patch.
> >
>
> What does the circumstance look like?
Well, in the PPC case, we had a hunk of RTL (created by the PPC backend) which
referenced the same hard register twice -- let's call them A0 and A1.
We want to replace (reg A0) with something like (plus (sp) (const_int)). and
replace (reg A1) with something else (some other register).
So before my changes, A0 and A1 would have the same register number, but
they would be distinct objects. replace_rtx would do the expected thing
and all was well.
After my changes A0 and A1 are the same object. And we end up replacing
both instances of that objects with (plus (ps) (const_int)). Not good.
I've got a fix for the ppc backend testing now (which should bring the
regression tester back into happy-ville for ppc). I see that it's
complaining about mips-elf, so there's probably something mucked up in
there too. Sigh...
jeff