This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR middle-end/19378: Fix AVR build failures / possibly less restrictive alternative.
- From: Björn Haase <bjoern dot m dot haase at web dot de>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org,Paul Schlie <schlie at comcast dot net>
- Date: Wed, 19 Jan 2005 08:45:28 +0100
- Subject: Re: [PATCH] PR middle-end/19378: Fix AVR build failures / possibly less restrictive alternative.
- References: <Pine.LNX.firstname.lastname@example.org>
Am Dienstag, 18. Januar 2005 23:36 schrieb Roger Sayle:
> On Wed, 19 Jan 2005, [iso-8859-1] Björn Haase wrote:
> > The following alternative patch removes the problem for the current head
> > revision by restricting the DI values to be allowed to be placed in all
> > registers except for the pointer registers.
> I think your patch is only working around the fundamental problems in
> avr.c's avr_hard_regno_mode_ok, which is slowly accumulating band-aids.
> For example, if you work through the code you'll notice that allocating
> an SImode register in r28 (when the frame pointer) is not required will
> also ICE when attempting to refer to the QImode highpart in r29.
I agree and I do not agree at the same time. Since all the SI instruction
patterns for avr presently do never access individual QI subregs, I do not
expect the problem that you have sketched to ever occure in practice. The
splitting toward QI mode presently happens only at assembly-output time.
> And as for determining when r28:r29 needs to be reserved for the frame
> pointer, avr.c already has severe schizophrenia using the predicate
> frame_pointer_required_p() in this function, but the global variable
> frame_pointer_needed everywhere else in avr.c.
Here I agree completely.
> I believe my patch is still the better solution, the latest revision
> of which I've attached below.
You're close to convincing me. I, however, would like to have a look at the
code size for some real-world applications before-hand.