This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR 6394
- From: Geoff Keating <geoffk at geoffk dot org>
- To: David Edelsohn <dje at watson dot ibm dot com>, "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: 30 Apr 2002 12:52:11 -0700
- Subject: Re: PR 6394
- References: <200204301728.NAA28138@makai.watson.ibm.com>
David Edelsohn <dje@watson.ibm.com> writes:
> >>>>> John David Anglin writes:
>
> John> This would be definitely helpful. I have investigated this enough
> John> to know that the floating pointer register is being allocated in
> John> global_alloc. What I don't understand is why this happens as it
> John> would seem that a general register should have been selected.
> John> The ICE occurs selecting one of two addresses for the return value
> John> and there shouldn't be many conflicts at this point.
>
> Alan Modra and the IBM ppc64 Linux team found similar bad register
> allocation for 64-bit PowerPC. As an interim solution, we added splitters
> that handle FP registers for those patterns to rs6000.md. I would suggest
> implementing something similar for PA-RISC GCC 3.1 or GCC 3.1.1.
>
> For GCC 3.2, we should focus on the new register allocator instead
> of trying to fix an inherently limited and broken implementation.
Did you work out _why_ reg-alloc was chosing this class (and which
class it was choosing)? Often these problems are actually caused by
the machine description, for instance by not having the union of two
register classes available, and a new register allocator won't help
that.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>