[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)
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
- [avr-gcc-list] Re: C vs. assembly performance, Nicholas Vinen, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Parthasaradhi Nayani, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance,
Georg-Johann Lay <=
- Re: [avr-gcc-list] Re: C vs. assembly performance, Nicholas Vinen, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Nicholas Vinen, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/02/28
- RE: [avr-gcc-list] Re: C vs. assembly performance, Weddington, Eric, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/02/28
- RE: [avr-gcc-list] Re: C vs. assembly performance, Weddington, Eric, 2009/02/28
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/02/28
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/02/28
- Re: [avr-gcc-list] Re: C vs. assembly performance, Bob Paddock, 2009/02/28