RE: [avr-gcc-list] Missed optimization or am *I* missing something?

[Weddington, Eric]

> -----Original Message-----
> From: Paulo Marques [mailto:address@hidden 
> Sent: Thursday, September 23, 2010 7:57 AM
> To: Weddington, Eric
> Cc: Johannes Bauer; address@hidden; Praveen, Vidya; 
> Singh, Abnikant
> Subject: Re: [avr-gcc-list] Missed optimization or am *I* 
> missing something?

Hi Paulo,
 
> 
> Yes, it seems that in the WEIRD=0 case, the compiler thinks the loop
> gets simple enough to be unrolled. If you look at the long version,
> there is no loop at all in it.

Blech. Why on earth does the compiler think that unrolling any loop produces 
*smaller* code when the user specifies -Os? We seriously need to look at the 
conditions that trigger that optimization.
 

> One thing I noticed a long time ago with avr-gcc (I haven't 
> checked more
> recent versions for this) is that splitting expressions into simpler
> ones helps the compiler detect that it doesn't need to upgrade the
> variables to 16 bit int's.
> 
> For instance, if you write the code as:
> 
>     unsigned char tmp;
> ...
>     offset = DMA.CH0.TRFCNT;
>     offset -= WEIRD;
>     boundedBufferValueSum = 0;
>     for (i = 0; i < 4; i++) {
>       tmp = offset;
>       tmp += i;
>       tmp += WEIRD;
>       tmp %= FOOBUFSIZE;
>         boundedBufferValueSum += fooBoundedBuffer[tmp];
>     }
> 
> you'll probably get smaller code. Yes, it's ugly, but if that function
> is in some hot path, it might be worth it...

True. However, we're at a point where we want to start fixing the compiler 
back-end so the user doesn't have to write code to adapt to the compiler's poor 
optimizations.

Eric