From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19978 invoked by alias); 7 Jul 2011 18:15:13 -0000 Received: (qmail 19960 invoked by uid 22791); 7 Jul 2011 18:15:11 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW 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, 07 Jul 2011 18:14:57 +0000 Received: by ewy5 with SMTP id 5so471852ewy.20 for ; Thu, 07 Jul 2011 11:14:56 -0700 (PDT) Received: by 10.14.98.131 with SMTP id v3mr344066eef.38.1310062496103; Thu, 07 Jul 2011 11:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.101.143 with HTTP; Thu, 7 Jul 2011 11:14:36 -0700 (PDT) In-Reply-To: <4E157B72.1000304@gjlay.de> 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> <4E03B658.8020509@redhat.com> <4E078F93.7060901@gjlay.de> <4E084291.4030300@gjlay.de> <4E157B72.1000304@gjlay.de> From: Denis Chertykov Date: Thu, 07 Jul 2011 18:21:00 -0000 Message-ID: Subject: Re: [Patch, AVR]: Fix PR46779 To: Georg-Johann Lay Cc: Richard Henderson , 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-07/txt/msg00539.txt.bz2 2011/7/7 Georg-Johann Lay : > Denis Chertykov wrote: >> 2011/6/27 Georg-Johann Lay: >>> Denis Chertykov wrote: > >>>> The main problem for me is that the new addressing mode produce a >>>> worse code in many tests. >>> You have an example source? >> >> In attachment. >> >> Denis. > > Hi Denis. > > I had a look at the sources you sent. > > sort.c: > =3D=3D=3D=3D=3D=3D=3D > > There is some difference because of register allocation, but the new > code does not look awfully bad, just a bit different because of > different register allocation that might need some more bytes. > > The difference is *not* because of deny fake X addressing, it's > because of the new avr_hard_regno_mode_ok implementation to fix > PR46779. =C2=A0When I add > > > =C2=A0if (GET_MODE_SIZE (mode) =3D=3D 1) > =C2=A0 =C2=A0 return 1; > > + =C2=A0 =C2=A0 if (SImode =3D=3D mode && regno =3D=3D 28) > + =C2=A0 =C2=A0 =C2=A0 return 0; > > =C2=A0 return regno % 2 =3D=3D 0; > > to that function, the difference in code disappears. > I have attached my version of addressing experiments. (on rietveld http://codereview.appspot.com/4674046/) It's against Richard's git://gcc.gnu.org/git/gcc.git rth/avr-addressing (may be you compare my regressions with your. It's interesting.) I still have a regression for sort.c (but I didn't analyzed the code): text data bss dec hex filename 364 0 0 364 16c /tmp/svn.o 446 0 0 446 1be /tmp/addr.o > pr.c: > =3D=3D=3D=3D=3D > > I get the following sizes with pr-0 the original compile and pr qith > my patch: > >>avr-size pr-0.o > =C2=A0 text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec =C2=A0 = =C2=A0 hex filename > =C2=A0 2824 =C2=A0 =C2=A0 =C2=A024 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A028= 48 =C2=A0 =C2=A0 b20 pr-0.o >>avr-size pr.o > =C2=A0 text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec =C2=A0 = =C2=A0 hex filename > =C2=A0 2564 =C2=A0 =C2=A0 =C2=A024 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A025= 88 =C2=A0 =C2=A0 a1c pr.o > > So the size actually decreased significantly. =C2=A0Avoiding SI in > avr_hard_regno_mode_ok like above does not change code size. Right now I'm also has a win for pr.c with new addressing code: text data bss dec hex filename 1226 24 0 1250 4e2 /tmp/svn.o 1176 24 0 1200 4b0 /tmp/addr.o But, from time to time (while experimenting) regression was here. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Note that I did *not* use the version from the git repository; I could > not get reasonable code out of it (even after some fixes). =C2=A0Hundreds > of testsuite crashes... IMHO it's because of `avr_frame_pointer_required_p' and `avr_can_eliminate'. (look at my attached patch) > > I used the initial patch that I posted; I attached it again for > reference. Note that LEGITIMIZE_RELOAD_ADDRESS is still not > implemented there. I think you can copy it from rth/addressing. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Did you decide about the fix for PR46779? > > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00810.html > > Is it ok to commit? I forgot about testsuite regressions for this patch. Denis.