[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Missed optimization or am *I* missing something?
From: |
Georg Lay |
Subject: |
Re: [avr-gcc-list] Missed optimization or am *I* missing something? |
Date: |
Mon, 27 Sep 2010 14:17:58 +0200 |
User-agent: |
Thunderbird 2.0.0.24 (X11/20100302) |
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