This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]