[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Another missed optimization

From: Eric Weddington
Subject: RE: [avr-gcc-list] Another missed optimization
Date: Thu, 09 Aug 2007 17:29:42 -0600

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Wouter van Gulik
> Sent: Thursday, August 09, 2007 8:21 AM
> To: address@hidden
> Subject: [avr-gcc-list] Another missed optimization
> Hi list,
> Ok I'll admit this one is rare, but a really annonying one. Since my
> application is all in one file I try to optimise the code (and
> especially my ISR's) by making heavily used variables reside in lower
> part registers. This reduces size a whole lot and speeds up a
> good bit.
> I know that instructions are restricted to handling r16..r31
> only. But
> this example should not suffer from this.
> Why is 0xA load again in r24?
> Strange enough gcc does optimise the extra ldi when r is not
> a explicit
> register.
> So it seems that the logic for writing register 15 and below is non
> optimal? I've seen misses when doing adding as well (I've not
> tried to
> reproduce it yet, will give it another try later)
> I used winavr-20070525 (GCC4.1.2) and the following compile options
> avr-gcc -S -Os -mmcu=atmega644 test.c
> Ok this is the c snippet:
> ////////////////////////// C ////////////////////////////////////
> register unsigned char r asm("r2"); //use only r2..r15

Hi Wouter,

I *really* appreciate the fact that you're taking a look at these
optimization issues. It's really needed. I would ask that you try these
tests *without* assigning a variable to a specific register like you do
above in assigning "r" to the r2 register. Most users would not do this and
it's really not recommended.

I also highly recommend that you report any optimization problems that you
find to the GCC bug database. Feel free to put my email address in the CC
list so I can track it. When these problems are only described in email they
have a tendency to get lost.

Eric Weddington

reply via email to

[Prev in Thread] Current Thread [Next in Thread]