Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
1. If you complain of missed optimisations, you should post the command line switches you have used, the -Ox switch at least. 2. Don't use the naked attribute if you don't understand its implications - here, main uses stack frame which has not been created due to naked; this might work only by coincidence (Y being set to a sane value in startup). 3. You should post the assembler output of compiler (which contains symbolic labels) or relevant portions of disassembled elf, rather than disassembled object with unresolved jump targets, which makes tracing the code difficult. 4. If you desire control over code size (and other aspects of the code too), resort to assembler. Jan Waclawek ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. With 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. (reports are that 4.5.2 produced smaller code than 4.3.2) Sorry for forgetting the commandline/etc in my report. I am using -Os, and compiling for m328p (I added conditionals so I can control from command line) I get: billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c billw@VB-Ubuntu$ avr-size foo.o text data bss dec hex filename 640 0 64 40 foo.o billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c billw@VB-Ubuntu$ avr-size foo.o text data bss dec hex filename 580 0 58 3a foo.o and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
Johann: I could reproduce it with one of the 4.7 packages (an older one) you provided. --- Moreover, in 4.7 it also stores the variable to stack frame even without naked, so that could be called a missed optimisation/regression. --- As far as code ineffiency goes, while there is always a chance that investigating that some otherwise covered bug could be revealed, I would not put much effort in it - you are simply not supposed to use naked for C functions. --- Sligtly OT, but once you reacted: 4. If you desire control over code size (and other aspects of the code too), resort to assembler. There is always that. At the moment, optiboot is a shining example of how the C compiler can generate output almost as small as assembler, and suitable for bootloaders and such. I never use the usual (and IMHO wrong) argument that assembler produces *smaller* code. Please note my wording. Jan Waclawek ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield wrote: On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. The only remarkable difference between 4.5.2 and 4.5.3 is the fix of PR42240. Depending on what distribution you use, your distributor added more patches, so we don't know. and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) Some of the diff noise is because of different debug symbols/labels; Hunans see more without -g because of reduces debug info noise. The other changes look reasonable with fix PR42240. You may also want to have a look at OS_task and OS_main function attributes. If an older toolchain works better for you, maybe you are fine with the older version. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote: I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8 With the attributes, the object size is 54 bytes. Without the attributes the object size is 64 bytes. 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. (reports are that 4.5.2 produced smaller code than 4.3.2) Sorry for forgetting the commandline/etc in my report. I am using -Os, and compiling for m328p I get: billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c billw@VB-Ubuntu$ avr-size foo.o textdata bss dec hex filename 64 0 0 64 40 foo.o billw@VB-Ubuntu$ avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c billw@VB-Ubuntu$ avr-size foo.o textdata bss dec hex filename 58 0 0 58 3a foo.o and more substantial diffs, including the following. naked deletes the prolog, but adds instructions in the body... -.LM7: +.LSM6: ldi r24,lo8(5) - rjmp .L8 + rcall putch + rjmp .L4 .L3: -.LM8: +.LSM7: cpi r24,lo8(-127) brne .L5 -.LM9: +.LSM8: ldi r24,lo8(4) - rjmp .L8 + rcall putch + rjmp .L4 .L5: -.LM10: +.LSM9: ldi r24,lo8(3) foo.c Description: Binary data ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On 27.01.2012 01:40, William Chops Westfield wrote: (reports are that 4.5.2 produced smaller code than 4.3.2) Hmmm... defiant joe [~/tmp]: avr-gcc -dumpversion 4.3.4 defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls foo.c defiant joe [~/tmp]: avr-size foo.o textdata bss dec hex filename 54 0 0 54 36 foo.o defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p -mshort-calls -DNAKED foo.c defiant joe [~/tmp]: avr-size foo.o textdata bss dec hex filename 52 0 0 52 34 foo.o Best regards, Joe ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William Chops Westfield wrote: Hi, don't forget to use reply to all or at least to CC the lists themselves. On Jan 27, 2012, at 3:23 AM, Georg-Johann Lay wrote: 4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2 and 4.5.3. The only remarkable difference between 4.5.2 and 4.5.3 is the fix of PR42240. That looks exactly relevant. The patch implements target hook TARGET_CANNOT_MODIFY_JUMPS_P in order to inhibit post-reload bb reorder for naked functions. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240 It looks like the patch to prevent reordering of instructions past the epilogue of naked functions prevents such reordering for the entire naked function. Yes. Though I'm not sure I understand why the original complaint was considered a bug. They appear to have been counting on a naked C function to fall in at the top and fall out at the bottom, which seems like even more of an abuse of naked than I was using (though I guess allowing that behavior is useful, especially in init code.) Thanks! BillW Yes. The reason why naked is there is that code can be put into .initN section. The code there is just like you lined out: enter at top an exit at bottom because such functions are not called, they are just collected and put in the respective .init section, one after one, like a pile of code. Naked will work with assembler code, but people also write C code to live in .init (making assumptions like there won't be a frame needed etc.). This means that you run into considerable problems if an epilogue (there may be more than one) is in the middle of the function. PR42240 fixes this and tries to make as much code as possible work together with naked at the expense of some additional instructions. OS_main/OS_task won't have the problem, but such functions cannot be used in .initN, of course. Except in the case where the code is in .init9 with custom startup code. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
William \Chops\ Westfield wes...@mac.com wrote: int main(void) __attribute__ ((naked)) __attribute__ ((section (.init9))); Instead of trying to force main into being naked, I think it would be better to use the OS_main attribute. Btw., please subscribe to the list. You might miss replies otherwise. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
Jan Waclawek schrieb: Moreover, in 4.7 it also stores the variable to stack frame even without naked, so that could be called a missed optimisation/regression. Thanks for pointing this out. I was lost in all that optimization conversation and thought it was an optimization issue from the first post. There is nothing written like program crashes because non-existent frame used. So the very problem is that there is a frame needed and there is none because of naked. Well, that's a bug in the user code, not in the application: You must not assume that the C code need no frame, even if it is a reasonable assumption like here. However, the frame is really strange and my first suspect is the evildoer: -fcaller-saves. That option causes evil in some places, or let me put things the other way round: In some cases -fno-caller-saves can avoid harm like spill fails in presence of high register pressure, see PR50925. Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
-Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Bill Westfield Sent: Friday, January 27, 2012 4:28 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3,re naked. Though I'm not sure I understand why the original complaint was considered a bug. They appear to have been counting on a naked C function to fall in at the top and fall out at the bottom, which seems like even more of an abuse of naked than I was using (though I guess allowing that behavior is useful, especially in init code.) Well, ideally, it should just be a non-main function that is set up as naked and placed in a .initN section. That means it doesn't have a function prologue and epilogue, i.e. it's not called from anywhere and doesn't return anywhere; it just runs in line, which is what you need to put C code in a .initN section. The main function should still be set up as a OS_main function, i.e. it doesn't return anywhere. Subtle differences. But I thought that all this was described in the avr-libc user manual (and/or GCC manual). If not, then maybe we need to add something to the avr-libc FAQ. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
To condense and summarize: Problem: optiboot, a very small bootloader, grows signficantly in binary size when going from gcc 4.5.2 to gcc 4.5.3. This turns out to be because it misses code factoring optimizations in optiboot's main() function, which is declared with attribute naked to save space. The missing optimizations are tied to naked; in sample programs the optimizations re-appear when the naked attribute is not used. Root cause: PR42240 is a patch that specifically disables jump modification in Naked functions, because they can interfere with proper exit handling of naked functions in .init sections. The .init sections are one of the primary intended uses for naked, while making main() naked is not a recommended practice (and in fact caused/uncovered other bugs in the optiboot code.) Resolution: optiboot will use the OS_main attribute instead of naked. It doesn't disable the optimization, the resulting code is small enough, and the attribute is more exactly appropriate and correct as well. It was probably an oversight that OS_main wasn't used in the first place. Thanks to all who assisted, especially Herr Lay, who identified the root cause! BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re naked.
On Jan 27, 2012, at 12:38 PM, Joerg Wunsch wrote: please subscribe to the list. You might miss replies otherwise. I am subscribed (at gmail); I've just be replying with the wrong from address :-( BillW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
