This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new-ra code sizes on Hitachi H8
- From: <tm_gccmail at mail dot kloo dot net>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: matz at suse dot de, gcc at gcc dot gnu dot org, law at redhat dot com,joern dot rennecke at superh dot com
- Date: Thu, 13 Feb 2003 11:41:05 -0800 (PST)
- Subject: Re: new-ra code sizes on Hitachi H8
On Thu, 13 Feb 2003, Kazu Hirata wrote:
> Hi Toshi,
>
> > The Hitachi H8 is a fairly difficult register-allocation situation -
> > only 8 general-purpose registers. So new-ra seems to be doing fairly
> > well. Only 4 testcases increased in size; the other 12 decreased in
> > size.
>
> This is impressive. Maybe I should help Michael Matz by running
> testsuite and other things with -fnew-ra. Thanks for reporting this.
> Also I am happy to see code size decreasing over the past few
> years. :-)
>
> Kazu Hirata
>
Just for fun, here's the data I generated for the SH last year while
tracking down code bloat issues:
-nrb
SH4 SH4-CVS SH4CVS SH4CVS SH4CVS SH4
file 3.0.2 7/17/2 8/8/2 9/6/2 10/15/2 2002r1
---------------------------------------------------------------
* layer3.i 3cb4 4b64 4900 4b20 4b20 4bc0
* l3bitstream.i 1894 1914 1740 18a0 18a0 18a0
* navion_aero.i 5e0 5a0 600 5c0 5c0 5a0
@ advdomestic.i 1d2c 1ee0 1a20 1ea0 1e80 1e80
@ aiunit.i 4374 4394 3e60 4320 43e0 43a0
@ chanserv.i de7c e12c c580 de20 dfc0 dfa0
@ melee2.i 60f4 5334 4fc0 5460 54a0 5480
@ wizard1.i 46f4 4474 4100 4700 4740 4700
+ adler32.i 130 114 120 120 120 120
+ blowfish.i 11f4 1188 1120 1160 1160 1160
+ imdecode.i 1ef38 1d754 1b0c0 1d7a0 1d880 1d8c0
+ map_fog.i 6bbc 8f20 72a0 73c0 73c0 7360
+ scanline.i 9c8 8f0 900 900 900 900
+ tif_fax3.i 1dec 1e08 1c00 1e00 1e00 1e00
. quantize.i 247c 23b8 2160 2360 2360 2360
. tif_packbits.i 4fc 4d8 4a0 480 4a0 4a0
. s_serv.i 666c 6148 5c00 6060 6060 6060
* = heavily floating-point testcase
@ = branchy testcase
+ = loopy testcase
. = mixed testcase
So basically, the code size delta between versions is fairly small, aside
from layer3.i which I need to investigate sometime.
Toshi