This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Effect of -fno-reorder-blocks?
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: dnovillo at redhat dot com, aj at suse dot de
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 12 Nov 2002 17:24:19 +0100
- Subject: Effect of -fno-reorder-blocks?
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
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