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

[Nicholas Vinen]

Georg-Johann Lay wrote:
> 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
Interesting. It may be that either I was using an earlier version which
missed these optimisations, or else it was because my code was much more
complex and the optimiser therefore missed them. I suppose I can go back
and find the old code, compile it, and see what comes out now. I forgot
about "andi", that makes it an even better optimisation, half as many
cycles and instructions.
>
>> 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...)
Yeah, this is one reason I haven't complained loudly in the past,
avr-gcc is already pretty good and I didn't want to apply a lot of
pressure to fix every little missed optimisation. However, it sure would
be nice. I'll see if I can dig up some of my old code now, before I
rewrote it in assembly. If it's still doing things the slow way I'll
point it out at the places you mention.

Thanks!


Nicholas