This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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>.
Hmm, then we have to trust my memory.
I am quite sure we run the benchmark and the result was positive
(unlike result of our first implementation of STC), but really don't
know where the result got lost.
Honza
>
> > 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