Re: [patch RFC] SH: Use FRAME_GROWS_DOWNWARD

[Joern RENNECKE <joern dot rennecke at st dot com>]

Kaz Kojima wrote:

> > I've run sim and CSiBE.  The results are here:
> >    
>
> I've run CSiBE for sh64-unknown-linux-gnu to see the effect of
> the FRAME_GROWS_DOWNWAR
> <20050708.230317.91336768.kkojima@rr.iij4u.or.jp> <42CE823F.1000009@st.com>DD  D patch for SHmedia.  Here is the result:
>
> CSiBE 2.1.0 Runtime result for sh64-unknown-linux-gnu
> (normalized with the original no-omit-fp result):
>
> 		original compiler		patched compiler
> 		no-omit-fp	omit-fp		no-omit-fp	omit-fp
>
> bzip2.c 	1 	 	1.00079 	1.00134 	1.00134   
> bzip2.d 	1 	 	0.998249 	1.00199 	0.995511  
> bzip2recover 	1 	 	0.928303 	1.00137 	0.925573  
> vam.fact 	1 	 	0.99613 	1.0029	 	0.997099  
> vam.fib 	1 	 	1.01091 	0.999089 	1.00727   
> vam.test2 	1 	 	1.02069 	1.02069 	1	   
> cjpeg2 	 	1 	 	0.996127 	0.985479 	0.984994  
> cjpeg0 	 	1 	 	0.970925 	0.944762 	0.953483  
> cjpeg1 	 	1 	 	1.00478 	0.988995 	0.983253  
> djpeg0 	 	1 	 	1 	 	0.995762 	1	   
> djpeg1 	 	1 	 	0.983944 	0.996788 	0.989081  
> djpeg2 	 	1 	 	1.00835 	1.01927 	0.991651  
> jpegtran0 	1 		1.02094 	0.937173 	1.00524   
> jpegtran1 	1 		0.98451 	0.974438 	0.977538  
> jpegtran2 	1 	 	0.973199 	0.995628 	0.971559  
> png2pnm0 	1 	 	1.0144 	 	0.996162 	1.0096	   
> png2pnm1 	1 	 	1.01266 	0.995594 	1.00512   
> pnm2png0 	1 	 	1.00735 	1.00399 	0.993699  
> pnm2png1 	1 	 	0.997001 	0.999488 	0.998098  
> src/hex/dehex0 	1 	 	0.986381 	0.992832 	0.985662  
> src/hex/dehex1 	1 	 	0.99481 	0.99481 	0.99713   
> src/hex/enhex0 	1 	 	0.992508 	0.995187 	0.995187  
> src/hex/enhex1 	1 	 	0.998319 	0.998073 	0.997007  
> minigzip 	1 	 	0.99012 	1 	 	1.00521   
> minigzip0 	1 	 	1.00615 	1.00636 	1.0006
>
>
> Again, it looks there are no big differences.  I've tested
> the patched mainline and sh-elf-4_1 compiler to build glibc
> and seen no problem too.  Are these tests enough for mainline?
>
> Regards,
> 	kaz
>  
Actually, I think that the differences are surprisingly large.  The SH5 
has 10 bit
scaled signed offsets, i.e. you can address +- 2KB worth of integers off 
the stack/
frame pointer.  Also the large impact of -fomit-frame-pointer surprises, 
particularily
for cjpeg0, considering that there are 63 general purpose registers.  
Differences
of more than one percent are unexpected.

Still, as far as I can see the speed is actually generally better with 
your patch, so
although it would be good to know why, that is not a reason to hold up 
the patch.

However, I think changing the frame direction is quite a profound change 
that should
get build are regression test coverage for a larger part of the SH 
subtarget spectrum.
If you can also build and regtest a complete (i.e. multilibbed) sh-elf 
toolchain without
regressions, it's OK.
Regression testing should cover at least one target without fp, and one with
double precision fp, and one big and one little endian target.  E.g. I 
commonly use
the default (SH1 big endian) and "-m4 -ml" (SH4 little endian) to get 
this coverage.
If you've already run the gcc/g++/objc regression tests on sh4-linux, we 
can count this
towards the floating point and little endian testing.