[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] Follow up to AVR-GCC -Os issues
From: |
Nicholas Vinen |
Subject: |
[avr-gcc-list] Follow up to AVR-GCC -Os issues |
Date: |
Fri, 09 Jan 2009 14:39:25 +1100 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090103) |
After further investigation I've noticed something odd.
Here is an example of a function which is much smaller with avr-gcc
4.1.2 than 4.3.2:
void calc_bin_values() {
charge_start_voltage_bin = decimal_to_binary(charge_start_voltage_dec,
5000);
charge_finish_voltage_bin = decimal_to_binary(charge_finish_voltage_dec,
5000);
charge_start_current_bin = decimal_to_binary(charge_start_current_dec,
1000);
charge_finish_current_bin = decimal_to_binary(charge_finish_current_dec,
1000);
}
This is what avr-gcc 4.1.2 produces with -Os -fno-inline-functions:
0000072c <calc_bin_values>:
72c: 68 e8 ldi r22, 0x88 ; 136
72e: 73 e1 ldi r23, 0x13 ; 19
730: 80 91 96 01 lds r24, 0x0196
734: 90 91 97 01 lds r25, 0x0197
738: 14 df rcall .-472 ; 0x562 <decimal_to_binary>
73a: 90 93 a1 01 sts 0x01A1, r25
73e: 80 93 a0 01 sts 0x01A0, r24
742: 68 e8 ldi r22, 0x88 ; 136
744: 73 e1 ldi r23, 0x13 ; 19
746: 80 91 9a 01 lds r24, 0x019A
74a: 90 91 9b 01 lds r25, 0x019B
74e: 09 df rcall .-494 ; 0x562 <decimal_to_binary>
750: 90 93 9f 01 sts 0x019F, r25
754: 80 93 9e 01 sts 0x019E, r24
758: 68 ee ldi r22, 0xE8 ; 232
75a: 73 e0 ldi r23, 0x03 ; 3
75c: 80 91 98 01 lds r24, 0x0198
760: 90 91 99 01 lds r25, 0x0199
764: fe de rcall .-516 ; 0x562 <decimal_to_binary>
766: 90 93 82 01 sts 0x0182, r25
76a: 80 93 81 01 sts 0x0181, r24
76e: 68 ee ldi r22, 0xE8 ; 232
770: 73 e0 ldi r23, 0x03 ; 3
772: 80 91 a2 01 lds r24, 0x01A2
776: 90 91 a3 01 lds r25, 0x01A3
77a: f3 de rcall .-538 ; 0x562 <decimal_to_binary>
77c: 90 93 ab 01 sts 0x01AB, r25
780: 80 93 aa 01 sts 0x01AA, r24
784: 08 95 ret
This seems about what I'd expect. Here's what avr-gcc 4.3.2 products
with the same options:
00000750 <calc_bin_values>:
750: 60 91 96 01 lds r22, 0x0196
754: 70 91 97 01 lds r23, 0x0197
758: 80 e0 ldi r24, 0x00 ; 0
75a: 90 e0 ldi r25, 0x00 ; 0
75c: 26 e0 ldi r18, 0x06 ; 6
75e: 34 e0 ldi r19, 0x04 ; 4
760: 40 e0 ldi r20, 0x00 ; 0
762: 50 e0 ldi r21, 0x00 ; 0
764: b3 d3 rcall .+1894 ; 0xecc <__mulsi3>
766: 28 e8 ldi r18, 0x88 ; 136
768: 33 e1 ldi r19, 0x13 ; 19
76a: 40 e0 ldi r20, 0x00 ; 0
76c: 50 e0 ldi r21, 0x00 ; 0
76e: ed d3 rcall .+2010 ; 0xf4a <__udivmodsi4>
770: 30 93 a1 01 sts 0x01A1, r19
774: 20 93 a0 01 sts 0x01A0, r18
778: 60 91 9a 01 lds r22, 0x019A
77c: 70 91 9b 01 lds r23, 0x019B
780: 80 e0 ldi r24, 0x00 ; 0
782: 90 e0 ldi r25, 0x00 ; 0
784: 26 e0 ldi r18, 0x06 ; 6
786: 34 e0 ldi r19, 0x04 ; 4
788: 40 e0 ldi r20, 0x00 ; 0
78a: 50 e0 ldi r21, 0x00 ; 0
78c: 9f d3 rcall .+1854 ; 0xecc <__mulsi3>
78e: 28 e8 ldi r18, 0x88 ; 136
790: 33 e1 ldi r19, 0x13 ; 19
792: 40 e0 ldi r20, 0x00 ; 0
794: 50 e0 ldi r21, 0x00 ; 0
796: d9 d3 rcall .+1970 ; 0xf4a <__udivmodsi4>
798: 30 93 9f 01 sts 0x019F, r19
79c: 20 93 9e 01 sts 0x019E, r18
7a0: 60 91 98 01 lds r22, 0x0198
7a4: 70 91 99 01 lds r23, 0x0199
7a8: 80 e0 ldi r24, 0x00 ; 0
7aa: 90 e0 ldi r25, 0x00 ; 0
7ac: 26 e0 ldi r18, 0x06 ; 6
7ae: 34 e0 ldi r19, 0x04 ; 4
7b0: 40 e0 ldi r20, 0x00 ; 0
7b2: 50 e0 ldi r21, 0x00 ; 0
7b4: 8b d3 rcall .+1814 ; 0xecc <__mulsi3>
7b6: 28 ee ldi r18, 0xE8 ; 232
7b8: 33 e0 ldi r19, 0x03 ; 3
7ba: 40 e0 ldi r20, 0x00 ; 0
7bc: 50 e0 ldi r21, 0x00 ; 0
7be: c5 d3 rcall .+1930 ; 0xf4a <__udivmodsi4>
7c0: 30 93 82 01 sts 0x0182, r19
7c4: 20 93 81 01 sts 0x0181, r18
7c8: 60 91 a2 01 lds r22, 0x01A2
7cc: 70 91 a3 01 lds r23, 0x01A3
7d0: 80 e0 ldi r24, 0x00 ; 0
7d2: 90 e0 ldi r25, 0x00 ; 0
7d4: 26 e0 ldi r18, 0x06 ; 6
7d6: 34 e0 ldi r19, 0x04 ; 4
7d8: 40 e0 ldi r20, 0x00 ; 0
7da: 50 e0 ldi r21, 0x00 ; 0
7dc: 77 d3 rcall .+1774 ; 0xecc <__mulsi3>
7de: 28 ee ldi r18, 0xE8 ; 232
7e0: 33 e0 ldi r19, 0x03 ; 3
7e2: 40 e0 ldi r20, 0x00 ; 0
7e4: 50 e0 ldi r21, 0x00 ; 0
7e6: b1 d3 rcall .+1890 ; 0xf4a <__udivmodsi4>
7e8: 30 93 ab 01 sts 0x01AB, r19
7ec: 20 93 aa 01 sts 0x01AA, r18
7f0: 08 95 ret
Note that it appears to be inlining the subroutine despite
-fno-inline-functions and this is causing it to produce much larger
code. I think -Os should inline functions if doing so reduces code size
- e.g. they are declared inline and only called in one place. This
subroutine (decimal_to_binary) is called in many places and is not
declared inline. Why is avr-gcc 4.3.2 inlining it, especially with -Os?
Nicholas
- [avr-gcc-list] Follow up to AVR-GCC -Os issues,
Nicholas Vinen <=