2011/6/16 Denis Chertykov <cherty...@gmail.com>: > 2011/6/16 Richard Henderson <r...@redhat.com>: >> On 06/15/2011 02:58 PM, Richard Henderson wrote: >>> Indeed, I can work around this particular crash by either >>> hacking Z to be call-saved, or hacking the frame pointer to >>> not be required. The former of course changes the abi, and >>> the second produces awful code due to too many copies from >>> the stack pointer. So neither option is "preferred". >> >> Perhaps I spoke too soon re the frame pointer. The old >> code is even worse. >> >> text data bss dec hex filename >> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o >> 5816 25 0 5841 16d1 bld-avr-new/gcc/z.o >> >> That said, there's a crash building libgcc so there's >> still work to do. > > @rth (while you are diving into AVR microworld ;-) > May be you can give a suggestion to change the AVR abi. > I have tuned the abi for code size almost 13 years ago. > The register pressure to r18-r31 are very high. > > I have a set of experiments with omitting the frame poiner and I found that > better to support fake addressing modes (infinite displacement for frame > pointer).
I forgot to said that suggestion from Bernd Schmidt about HARD_FRAME_POINTER_REGNUM seems very useful: > Maybe it would help for your port to define a separate > FRAME_POINTER_REGNUM, able to hold an HImode value, which then gets > eliminated to HARD_FRAME_POINTER_REGNUM? This mechanism is used on many > other ports if you need examples. It's not related to addressing modes but it's related to frame pointer bugs. Denis.
