This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Effect of -fno-reorder-blocks?
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: jh at suse dot cz
- Cc: hans-peter dot nilsson at axis dot com, dnovillo at redhat dot com, aj at suse dot de, gcc at gcc dot gnu dot org
- Date: Mon, 18 Nov 2002 20:31:28 +0100
- Subject: Re: Effect of -fno-reorder-blocks?
> Date: Mon, 18 Nov 2002 20:16:50 +0100
> From: Jan Hubicka <jh@suse.cz>
> > 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.
Sorry, I see no mention of -fno-reorder-blocks on that page or
in the immediate links, specifically not at
<URL:http://www.suse.de/~aj/SPEC/compare-flags.html>.
> 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.
Sounds interesting.
brgds, H-P