2011/6/16 Richard Henderson <r...@redhat.com>: > On 06/16/2011 04:34 AM, Denis Chertykov wrote: >> @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. > > As far as I can see, the ABI is pretty good. There's nothing > that I would say that should obviously be changed. > > I might totally drop support for DImode. Let "long long" map > to SImode. If you want 64-bit data, you probably don't want > to select an 8-bit microcontroller. > > That might take a bit of surgery on the way we currently build > libgcc though. > >> 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). > > The biggest problem that I see, from the 950612-1.c test case > with the current handling of the "infinite displacement frame > pointer", is that the adjustments to the frame pointer are > never exposed as separate instructions, so there's never a > chance to optimize them.
Yes. I'm agree. > So once you build a stack frame larger than 64 bytes, things > get worse and worse. May be something like this: The port must not permit infinite displacements before reload. (all addressing modes must have a right form) Fake addressing mode enabled only after reload_in_progress. (only small part of spilled/local variables will be addressed by fake addressing mode.) I don't like fake addressing mode and I don't want to support it at all, but may be it's a best way to work around 'unable to find a register to spill' problem. (the current AVR addressing code written in this way) > You wind up with code like > > subi r28,lo8(-133) > sbci r29,hi8(-133) > ld r18,Y > subi r28,lo8(133) > sbci r29,hi8(133) > subi r28,lo8(-134) > sbci r29,hi8(-134) > ld r19,Y > subi r28,lo8(134) > sbci r29,hi8(134) > > where obviously the 4 middle instructions could be eliminated. > > If we came out of reload (or shortly thereafter via split) with > these as separate patterns, we might be able to eliminate them > via an existing optimization pass. OTOH, an existing pass might > refuse to operate on the frame pointer because the frame pointer > is usually Special. IMHO the source of the problem is a REGISTER ALLOCATOR because it is not handle a register elimination and strict insn constraints. Denis.
