Re: [Patch, AVR]: Fix PR46779

[Richard Henderson <rth@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.

So once you build a stack frame larger than 64 bytes, things
get worse and worse.  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.

One could write an avr-specific pass for this:
  Scan the code for references to the frame pointer.
  Record the offsets of the uses.
  Compute a sliding 64-byte window that satisfies the maximum
	number of uses within the region.
  Insert adjustments to the frame pointer.
  Arrange for the dwarf2out routines to scan the whole function.
	(If alloca has been used, the frame pointer anchors the
	CFA, and the unwind info will need adjusting throughout
	the function.  Otherwise gdb will fail entirely.)

That last point probably depends on Bernd Schmidt's work in
dwarf2out for shrink-wrapping...


r~