Weddington, Eric schrieb: > > >> -----Original Message----- >> From: Paulo Marques [mailto:pmarq...@grupopie.com] >> Sent: Thursday, September 23, 2010 7:57 AM >> To: Weddington, Eric >> Cc: Johannes Bauer; avr-gcc-list@nongnu.org; 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
