From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29714 invoked by alias); 16 Jun 2011 18:10:39 -0000 Received: (qmail 29705 invoked by uid 22791); 16 Jun 2011 18:10:39 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ew0-f47.google.com (HELO mail-ew0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Jun 2011 18:10:21 +0000 Received: by mail-ew0-f47.google.com with SMTP id 5so737586ewy.20 for ; Thu, 16 Jun 2011 11:10:20 -0700 (PDT) Received: by 10.14.99.71 with SMTP id w47mr496021eef.221.1308247819369; Thu, 16 Jun 2011 11:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.186.16 with HTTP; Thu, 16 Jun 2011 11:09:59 -0700 (PDT) In-Reply-To: <4DFA124F.1090504@redhat.com> References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> <4DF73490.2080709@gjlay.de> <4DF7D2B5.1090708@gjlay.de> <4DF8ED42.1030706@redhat.com> <4DF918A9.4070003@gjlay.de> <4DF92AEA.4000906@redhat.com> <4DF93B17.8020008@redhat.com> <4DFA124F.1090504@redhat.com> From: Denis Chertykov Date: Thu, 16 Jun 2011 18:57:00 -0000 Message-ID: Subject: Re: [Patch, AVR]: Fix PR46779 To: Richard Henderson Cc: Georg-Johann Lay , gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01282.txt.bz2 2011/6/16 Richard Henderson : > 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. =C2=A0There's nothing > that I would say that should obviously be changed. > > I might totally drop support for DImode. =C2=A0Let "long long" map > to SImode. =C2=A0If 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 t= hat >> 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) > =C2=A0You wind up with code like > > =C2=A0 =C2=A0 =C2=A0 =C2=A0subi r28,lo8(-133) > =C2=A0 =C2=A0 =C2=A0 =C2=A0sbci r29,hi8(-133) > =C2=A0 =C2=A0 =C2=A0 =C2=A0ld r18,Y > =C2=A0 =C2=A0 =C2=A0 =C2=A0subi r28,lo8(133) > =C2=A0 =C2=A0 =C2=A0 =C2=A0sbci r29,hi8(133) > =C2=A0 =C2=A0 =C2=A0 =C2=A0subi r28,lo8(-134) > =C2=A0 =C2=A0 =C2=A0 =C2=A0sbci r29,hi8(-134) > =C2=A0 =C2=A0 =C2=A0 =C2=A0ld r19,Y > =C2=A0 =C2=A0 =C2=A0 =C2=A0subi r28,lo8(134) > =C2=A0 =C2=A0 =C2=A0 =C2=A0sbci 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. =C2=A0OTOH, 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.