| Summary: | avr wrong size in asm comment (peephole) | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Dmitry K. <dmixm> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | eric.weddington, gcc-bugs |
| Priority: | P5 | ||
| Version: | 4.0.0 | ||
| Target Milestone: | 4.3.0 | ||
| Host: | Target: | avr | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2005-03-10 14:20:10 | |
I can confirm this for gcc-4.0.0-20050228 This is almost certainly caused by code peepholes doing last minute optimisation of the code just before the assembler is generated. Prior to that, all RTL instructions have a length (in 16 bit words) that is *soley* used to select the appropriate jump and branch instructions. The size comments are generated from those lengths. If a peephole does indeed change some instructions, they will quite likely over estimate the final size (as is the case presented here) The length (and so size) is fine if it over estimates the actual size (Jumps/branches can always work over shorter distances.) The actual jump displacments are based on labels so they are unaffected. There may be some other areas of the backend that apply worse-case estimates of asm instruction size to avoid the complexity of calculating every situation. However, peepholes definitely do this! I would suggest this is a non-bug as the size is an internal compiler debug comment and there is no regression, misoptimisation or similar downside. If the size ever under-estimates the true size THAT IS A BUG! Also note peepholes should really be changed to peephole2. The code that which print size of prologue and epilogue was removed when avr port was switched from asm-prologue/epilogue to RTL-prologue/epilogue. Anatoly. Fixed in trunk. |
Comment about function `foo' size: 27 /* function foo size 10 (9) */ show wrong value. (Compare it with next function.) Compiler: avr-gcc (GCC) 4.0.0 20050109 (experimental) Options: -W -Wall -Os -Wa,-ahl The same error (for `foo') in 3.3.4 . Certainly, it is nonsense. But, maybe, this display of more serious mistake? Program: ~~~~~~~~ int foo (int x) { int i; for (i= 10; i; i--) x *= 2; return x; } int foo_with_true_size (int x) { x += 100; do { x *= 2; } while (x > 0); return x; } Listing: ~~~~~~~~ GAS LISTING /tmp/ccJGSrye.s page 1 1 .file "foo.c" 2 .arch avr2 3 __SREG__ = 0x3f 4 __SP_H__ = 0x3e 5 __SP_L__ = 0x3d 6 __tmp_reg__ = 0 7 __zero_reg__ = 1 8 .global __do_copy_data 9 .global __do_clear_bss 10 .text 11 .global foo 12 .type foo, @function 13 foo: 14 /* prologue: frame size=0 */ 15 /* prologue end (size=0) */ 16 0000 2AE0 ldi r18,lo8(10) 17 0002 30E0 ldi r19,hi8(10) 18 .L2: 19 0004 880F add r24,r24 20 0006 991F adc r25,r25 21 0008 2150 subi r18,lo8(-(-1)) 22 000a 3040 sbci r19,hi8(-(-1)) 23 000c D9F7 brne .L2 24 /* epilogue: frame size=0 */ 25 000e 0895 ret 26 /* epilogue end (size=1) */ 27 /* function foo size 10 (9) */ 28 .size foo, .-foo 29 .global foo_with_true_size 30 .type foo_with_true_size, @function 31 foo_with_true_size: 32 /* prologue: frame size=0 */ 33 /* prologue end (size=0) */ 34 0010 8C59 subi r24,lo8(-(100)) 35 0012 9F4F sbci r25,hi8(-(100)) 36 .L8: 37 0014 880F add r24,r24 38 0016 991F adc r25,r25 39 0018 1816 cp __zero_reg__,r24 40 001a 1906 cpc __zero_reg__,r25 41 001c DCF3 brlt .L8 42 /* epilogue: frame size=0 */ 43 001e 0895 ret 44 /* epilogue end (size=1) */ 45 /* function foo_with_true_size size 8 (7) */ 46 .size foo_with_true_size, .-foo_with_true_size 47 /* File "foo.c": code 18 = 0x0012 ( 16), prologues 0, epilogues 2 */