This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, AVR]: Fix PR46779
- From: Denis Chertykov <chertykov at gmail dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, Anatoly Sokolov <aesok at post dot ru>, "Eric B. Weddington" <eric dot weddington at atmel dot com>
- Date: Thu, 7 Jul 2011 22:14:36 +0400
- Subject: Re: [Patch, AVR]: Fix PR46779
- References: <4DF0FAB5.6070704@gjlay.de> <BANLkTi=1v9KGgCL0V0+i=LOtbCh51FLm+A@mail.gmail.com> <4DF11D20.4030907@gjlay.de> <BANLkTi=VAo8UcLDsvBp5vWk3qaO5RQvAKg@mail.gmail.com> <4DF1ED76.4030507@gjlay.de> <BANLkTi=P0zopComgS6FDZ=cg3s9sDuKNHg@mail.gmail.com> <4DF650B7.3030705@gjlay.de> <BANLkTimPjxMw48oExFWLtDcdB=3nb_VH0g@mail.gmail.com> <4DF73490.2080709@gjlay.de> <BANLkTim=EZDDtSxpE0b0aU7wjcxynsyUqg@mail.gmail.com> <4DF7D2B5.1090708@gjlay.de> <4DF8ED42.1030706@redhat.com> <4DF918A9.4070003@gjlay.de> <4DF92AEA.4000906@redhat.com> <4DF93B17.8020008@redhat.com> <BANLkTimrSz4-0tTw-iai0g=6Ry-jQ+ydTQ@mail.gmail.com> <4E03B658.8020509@redhat.com> <BANLkTimiQLH+=0QJV8ELx+6s_NXKaKPv_g@mail.gmail.com> <4E078F93.7060901@gjlay.de> <BANLkTim3q=v5dc-ja6bHjvzVAtAf-PVy0g@mail.gmail.com> <4E084291.4030300@gjlay.de> <BANLkTikx_eDGT7KT+B_X0nTT0wAzYe7DBg@mail.gmail.com> <4E157B72.1000304@gjlay.de>
2011/7/7 Georg-Johann Lay <avr@gjlay.de>:
> 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:
> =======
>
> 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. ÂWhen I add
>
>
> Âif (GET_MODE_SIZE (mode) == 1)
> Â Â return 1;
>
> + Â Â if (SImode == mode && regno == 28)
> + Â Â Â return 0;
>
> Â return regno % 2 == 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:
> =====
>
> I get the following sizes with pr-0 the original compile and pr qith
> my patch:
>
>>avr-size pr-0.o
>  text  Âdata   bss   dec   hex filename
> Â 2824 Â Â Â24 Â Â Â 0 Â Â2848 Â Â b20 pr-0.o
>>avr-size pr.o
>  text  Âdata   bss   dec   hex filename
> Â 2564 Â Â Â24 Â Â Â 0 Â Â2588 Â Â a1c pr.o
>
> So the size actually decreased significantly. ÂAvoiding 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.
>
> ============
>
> 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). ÂHundreds
> 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.
>
> ============
>
> 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.