Effect of -fno-reorder-blocks?

[Jan Hubicka]

> I see unexpected results with a ss of gcc-3.2 (gcc-20020902).  I
> get better code with -fno-reorder-blocks *especially*
> considering effects on the cache (a simple one: 8k unified
> 1-way, 32-byte lines) for cris-axis-linux-gnu.  I'll add more
> substance to this claim once I've done more thorough testing,
> with newer sources, though I believe no changes have been done
> that would improve this.  I wonder if there are similar effects
> for other architectures, with more intricate branch timings and

Andreas made some benchmarking on Athlon and there it seems to help.
You can see http://www.suse.de/~aj/SPEC and look for options study.

It is interesting to see that it does not help for some architectures
(as P4 results suggest).  We can benchmark Josef's software trace cache
implementation.  That algorithm should reduce code size trashing
according to author's but we are having hard time to tune it on Athlon.
perhaps we should try more architectures.

Honza

> cache semantics.  I know about the the messages about SH and
> -fno-reorder-blocks; that's the reason I tried it.
> 
> If this is simple for you to check, can I please ask you to do a
> comparative SPECint{95, 2000} run with and without
> -fno-reorder-blocks together with whatever other flags you use
> with -O2, for main trunk and perhaps also the 3.2 branch?  If
> not, I'll eventually do it myself for SPECint2000.  I have a
> license.  Maybe it has been done before, but I can't find any
> references.
> 
> If not, can I please have a copy of the scripts used to simplify
> the SPEC setup and result comparison?  (Perhaps they can be
> added to gcc/contrib/?)
> 
> brgds, H-P