[Top][All Lists]

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

Re: [avr-gcc-list] Re: C vs. assembly performance

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Date: Sat, 28 Feb 2009 13:09:24 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Nicholas Vinen schrieb:
* On the other hand, it would be great if avr-gcc could perform some
basic optimisations that even a fairly inexperienced amateur could
manage. For example, things like "unsigned char x, y; x = y>>4" could
use the nibble swap instruction rather than four shifts, and things like

The compiler uses swap if it can. Maybe there are some effects of implicit type conversion like
   unsigend char x, y, z; z = (x+y) >> 4;
which is quite different from
   z = x >> 4;

"unsigned short a; unsigned char b; b = a>>8" could pretty much just be
a single instruction. These are examples of things I've seen the
compiler waste cycles on, that are fairly obvious. In future if I see

compiling the following code
unsigned char sh4 (unsigned char x)
    return x >> 4;

unsigned char sh8 (unsigned short x)
    return x >> 8;

with avr-gcc 4.3.2 and -Os yields (non-code stripped)

        swap r24         ;
        andi r24,lo8(15)         ; ,

        mov r24,r25      ; , x

the compiler doing silly things like this, is it worth me posting the
code & assembly output to this list?
If you are sure it is really some performance issue/regression and not due to some language standard implication, you can add a report to

so that the subject won't be forgotten. Also mind

And of course, you can ask questions here. In that case it is helpful if you can manage to simplify the source to a small piece of code that triggers the problem and allows others to reproduce the problem. (i.e. no #include in the code, no ... (except for varargs), a.s.o).

Snippets of .s may point to the problem when you add -dp -fverbose-asm

And there are lots of places where avr-gcc produces suboptimal or even bad code, so feedback is welcome.

But note that just a few guys are working on the AVR part of gcc.
I would do more if I had the time (and the support of some gurus to ask questions on internals then and when...)



reply via email to

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