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...)
#include <avr/io.h>
int main(void) {
unsigned long packet = 0;
while(1) {
if( !(PINC & _BV(PC2)) ) {
packet = (packet<<1)|(((unsigned char)PINC>>1)&1);
}
PORTB = packet;
}
}
lsl r18 ; packet ; 50 *ashlsi3_const/2 [length = 4]
rol r19 ; packet
rol r20 ; packet
rol r21 ; packet
in r24,38-0x20 ; D.1214, ; 16 *movqi/4 [length = 1]
lsr r24 ; D.1214 ; 17 lshrqi3/3 [length = 1]
ldi r25,lo8(0) ; , ; 48 *movqi/2 [length = 1]
ldi r26,lo8(0) ; , ; 46 *movhi/4 [length = 2]
ldi r27,hi8(0) ; ,
andi r24,lo8(1) ; tmp52, ; 19 andsi3/2 [length = 4]
andi r25,hi8(1) ; tmp52,
andi r26,hlo8(1) ; tmp52,
andi r27,hhi8(1) ; tmp52,
or r18,r24 ; packet, tmp52 ; 20 iorsi3/1 [length = 4]
or r19,r25 ; packet, tmp52
or r20,r26 ; packet, tmp52
or r21,r27 ; packet, tmp52
lsl r18
rol r19
rol r20
rol r21
in r24,38-0x20
bst r24, 1
bld r18, 0