From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14437 invoked by alias); 12 Jun 2011 09:02:27 -0000 Received: (qmail 14427 invoked by uid 22791); 12 Jun 2011 09:02:26 -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-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 12 Jun 2011 09:02:12 +0000 Received: by eye27 with SMTP id 27so1498044eye.20 for ; Sun, 12 Jun 2011 02:02:11 -0700 (PDT) Received: by 10.14.1.71 with SMTP id 47mr1714095eec.128.1307869331134; Sun, 12 Jun 2011 02:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.186.16 with HTTP; Sun, 12 Jun 2011 02:01:51 -0700 (PDT) In-Reply-To: <4DF1ED76.4030507@gjlay.de> References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> From: Denis Chertykov Date: Sun, 12 Jun 2011 10:34:00 -0000 Message-ID: Subject: Re: [Patch, AVR]: Fix PR46779 To: Georg-Johann Lay Cc: 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/msg00930.txt.bz2 2011/6/10 Georg-Johann Lay : > Then I have a question on spill failures: > > There is PR46278, an optimization flaw that goes as follows: > > The avr BE defines fake addressing mode X+const that has to be written > down in asm as > =C2=A0X +=3D const > =C2=A0a =3D *X > =C2=A0X -=3D const > > The comment says that this is just to cover a corner case, however the > new register allocator uses this case more often or even greedily. > There is no way to describe the cost for such an access, and as X has > lower prologue/epilogue cost than Y, X is preferred over Y often. > > In 4.7, I see that flaw less often than in 4.5. =C2=A0However, I think the > best way is not to lie at the register allocator and not to supply a > fake instruction like that. > > So I started to work on a fix. The changes in avr.h are: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0* config/avr/avr.h (BASE_REG_CLASS): Remove. > =C2=A0 =C2=A0 =C2=A0 =C2=A0(REG_OK_FOR_BASE_NOSTRICT_P): Remove. > =C2=A0 =C2=A0 =C2=A0 =C2=A0(REG_OK_FOR_BASE_STRICT_P): Remove. > =C2=A0 =C2=A0 =C2=A0 =C2=A0(MODE_CODE_BASE_REG_CLASS): New Define. > =C2=A0 =C2=A0 =C2=A0 =C2=A0(REGNO_MODE_CODE_OK_FOR_BASE_P): New Define. > > The macros REGNO_MODE_CODE_OK_FOR_BASE_P and MODE_CODE_BASE_REG_CLASS > allow a better, fine grained control over addressing modes for each > hard register and allow to support X without fake instructions. The > code quality actually improves, but I see a new spill failure for the > test case > > * gcc.c-torture/compile/950612-1.c > > On the one hand, that test case has heavy long long use and is no > "real world code" to run on AVR. On the other hand, I don't think > trading code quality here against ICE there is a good idea. > > What do you think about that? As I have no idea how to fix a spill > failure in the backend, I stopped working on a patch. Ohhh. It's a most complicated case for GCC for AVR. Look carefully at `out_movqi_r_mr'. There are even two fake addressing modes: 1. [Y + infinite-dslacement]; 2. [X + (0...63)]. I have spent a many hours (days, months) to debug GCC (especially avr port and reload) for right addressing modes. I have stopped on this code. AVR have a limited memory addressing and GCC can't handle it in native form. Because of that I have supported a fake adddressing modes. (Richard Henderson have a different oppinion: GCC can, AVR port can't) IMHO that three limited pointer registers is not enough for C compiler. Even more with frame pointer it's only two and X is a very limited. 1. [Y + infinite-dslacement] it's helper for reload addressing. For addressing too long local/spilled variable. (Y + more-than-63) 2. [X + (0...63)] for another one "normal" pointer address. > Then I observed trouble with DI patterns during libgcc build and had > to remove > > * "zero_extendqidi2" > * "zero_extendhidi2" > * "zero_extendsidi2" > > These are "orphan" insns: they deal with DI without having movdi > support so I removed them. This seems strange for me. Denis.