avr-gcc-list
[Top][All Lists]
Advanced

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

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


From: Paulo Marques
Subject: Re: [avr-gcc-list] Missed optimization or am *I* missing something?
Date: Thu, 23 Sep 2010 14:57:13 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Weddington, Eric wrote:
> Hi Johannes,

Hi, Eric

> My best guess is that this is a missed optimization. The compiler is
> probably selecting different patterns based on the different code. It
> recognizes the redundant adding of zero in the operations below when
> WEIRD is 0 and rightly throws them out. When WEIRD is 1, those
> operations have to be kept in, and so different patterns are selected,
> which are either more optimal, or triggers different kinds of
> optimizations to take place afterwards, hence producing better code even
> though there are more operations. I noticed that the longer code
> generates a lot more code with the pointer registers (Z and X in this case).

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.

> I noticed too that the more optimal case below is still not the best
> code: it looks like the index variable 'i' in your for loop is being
> treated as a 16-bit value, when you explicitly declare it as an 8-bit
> unsigned char. Fixing that could save another 3 instructions.

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...

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"This version has many new and good features. Sadly, the good ones are
not new and the new ones are not good."



reply via email to

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