>> > >I am completely in line with Eric: Your debugger will have to get smarter >and >not the compiler get dumb again. > >Johann As it was put, it is more of a performance question than about the correctness of it. I am not sure what exactly the issue is, but you are right that one cannot rely on rcall/ret matching sequences. At first glance it appeared that the although we are achieving both performance and size gain using rcall for stack allocation, the code looked very misleading. Hence I suggested making it optional. On second thoughts, I am taking it back :) Anitha _______________________________________________ AVR-GCC-list mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Boyapati, Anitha
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Boyapati, Anitha
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Weddington, Eric
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Georg-Johann Lay
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue v... Weddington, Eric
- Re: [avr-gcc-list] [AVR] RTL prologue/epilog... Georg-Johann Lay
- Re: [avr-gcc-list] [AVR] RTL prologue/ep... Weddington, Eric
- Re: [avr-gcc-list] [AVR] RTL prolog... Georg-Johann Lay
- Re: [avr-gcc-list] [AVR] RTL pr... Weddington, Eric
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue v... Boyapati, Anitha
- Re: [avr-gcc-list] [AVR] RTL prologue/epilogue v... Boyapati, Anitha
- Re: [avr-gcc-list] [AVR] RTL prologue/epilog... Georg-Johann Lay
