avr-gcc-list
[Top][All Lists]
Advanced

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

[avr-gcc-list] regression in size from 4.2.2 to 4.5.0


From: Sean D'Epagnier
Subject: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0
Date: Wed, 6 May 2009 12:44:42 -0600

Hi,

I was trying to reduce the size of my binary so it would fit on some
128kb parts.  I normally used gcc 4.2.2 for this project, but decided
to try gcc 4.5.0.  To my surprise, the resulting binary was 3.5kb
_larger_ with the newer gcc.  This is a serious bug imho and should be
fixed.  I'm not quite sure why it did occur, but I have some guesses.
I have here the old (4.2.2 gcc) then the new (4.5.0 gcc) disassembly:

0001d5a2 <USB_Init>:
   1d5a2:       1f 93           push    r17
   1d5a4:       18 2f           mov     r17, r24
   1d5a6:       80 91 32 15     lds     r24, 0x1532
   1d5aa:       88 23           and     r24, r24
   1d5ac:       09 f0           breq    .+2             ; 0x1d5b0 <USB_Init+0xe>
   1d5ae:       dd df           rcall   .-70            ; 0x1d56a <USB_ShutDown>
   1d5b0:       80 91 d7 00     lds     r24, 0x00D7
   1d5b4:       80 68           ori     r24, 0x80       ; 128
   1d5b6:       80 93 d7 00     sts     0x00D7, r24
   1d5ba:       81 e0           ldi     r24, 0x01       ; 1
   1d5bc:       80 93 32 15     sts     0x1532, r24
   1d5c0:       80 91 d8 00     lds     r24, 0x00D8
   1d5c4:       80 61           ori     r24, 0x10       ; 16
   1d5c6:       80 93 d8 00     sts     0x00D8, r24
   1d5ca:       10 93 2e 15     sts     0x152E, r17
   1d5ce:       80 91 d8 00     lds     r24, 0x00D8
   1d5d2:       81 60           ori     r24, 0x01       ; 1
   1d5d4:       80 93 d8 00     sts     0x00D8, r24
   1d5d8:       78 94           sei
   1d5da:       1f 91           pop     r17
   1d5dc:       08 95           ret

0001e688 <USB_Init>:
   1e688:       a1 e0           ldi     r26, 0x01       ; 1
   1e68a:       b0 e0           ldi     r27, 0x00       ; 0
   1e68c:       e9 e4           ldi     r30, 0x49       ; 73
   1e68e:       f3 ef           ldi     r31, 0xF3       ; 243
   1e690:       a8 c3           rjmp    .+1872          ; 0x1ede2 
<__prologue_saves__+0x20>
   1e692:       90 91 da 13     lds     r25, 0x13DA
   1e696:       99 23           and     r25, r25
   1e698:       19 f0           breq    .+6             ; 0x1e6a0 
<USB_Init+0x18>
   1e69a:       89 83           std     Y+1, r24        ; 0x01
   1e69c:       d9 df           rcall   .-78            ; 0x1e650 <USB_ShutDown>
   1e69e:       89 81           ldd     r24, Y+1        ; 0x01
   1e6a0:       90 91 d7 00     lds     r25, 0x00D7
   1e6a4:       90 68           ori     r25, 0x80       ; 128
   1e6a6:       90 93 d7 00     sts     0x00D7, r25
   1e6aa:       91 e0           ldi     r25, 0x01       ; 1
   1e6ac:       90 93 da 13     sts     0x13DA, r25
   1e6b0:       90 91 d8 00     lds     r25, 0x00D8
   1e6b4:       90 61           ori     r25, 0x10       ; 16
   1e6b6:       90 93 d8 00     sts     0x00D8, r25
   1e6ba:       80 93 d6 13     sts     0x13D6, r24
   1e6be:       80 91 d8 00     lds     r24, 0x00D8
   1e6c2:       81 60           ori     r24, 0x01       ; 1
   1e6c4:       80 93 d8 00     sts     0x00D8, r24
   1e6c8:       78 94           sei
   1e6ca:       21 96           adiw    r28, 0x01       ; 1
   1e6cc:       e2 e0           ldi     r30, 0x02       ; 2
   1e6ce:       a5 c3           rjmp    .+1866          ; 0x1ee1a 
<__epilogue_restores__+0x20>


As you can see, the new gcc is calling epilogue store and restore
where the old gcc did not.  This significantly increases my binary
size (not to mention slows the runtime speed)    This is not the only
problem though :(


I have another function which increased in size by 500 bytes.. this is
huge for a single function, and both old and new gcc both call
epilogue save and restores for this.   For that case, I attached the C
code, followed by old then new gcc output.

Sorry for my lack of information, I would like to work toward not only
fixing these problems, but also improving gcc so it can output smaller
code than ever.  Unfortunately I think many of the problems in gcc
exist for all targets.

Thanks,
Sean

Attachment: gcc-regression.txt
Description: Text document


reply via email to

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