Re: [Patch, AVR]: Fix PR46779

[Denis Chertykov <chertykov at gmail dot com>]

2011/6/16 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.

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.