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

[Georg-Johann Lay]

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)

sh4:
        swap r24         ;
        andi r24,lo8(15)         ; ,
        ret

sh8:
        mov r24,r25      ; , x
        ret

> 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
    http://sourceforge.net/tracker/?group_id=68108

so that the subject won't be forgotten. Also mind
    http://gcc.gnu.org/bugs.html

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

> Nicholas
Georg-Johann