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

[Georg Lay]

Weddington, Eric schrieb:
>  
> 
>> -----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

Hi Eric. This is surely no flaw of the avr backend. I observed it some time ago
but got no answer from the compiler gurus:
   http://gcc.gnu.org/ml/gcc-help/2009-01/msg00237.html

Best reduce it to a small testcase and post a gcc bug report.

Greets, Georg