This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Should -fcross-jumping be part of -O1?
Jan Hubicka wrote:
crossjumping has been -O1 thing forever, but I would also agree that
it should be disabled at -O1. At minimum it may get compile time
expensive in some cases.
If "-fcrossjumping" has been part of -O1 "forever", as you say, why
wasn't it mentioned in the man pages prior to GCC 3.3? This is one
reason I missed testing it in earlier incarnations of gccacovea.
Version 3.1 of Acovea (to be posted mid-week) now tests some 65 options
(as opposed to 55 in Avocea 3.0.0).
Do you have testcases that ere pessimized at -O2? -fcrossjumping may
introduce new branches that are supposed to be elliminated by basic
block reordering not done at -O1.
Pentium 4 results for the huffbench.c test:
37.8s -O1
34.0s -O1 -fno-crossjumping
31.7s -O2
30.3s -O2 -fno-crossjumping
30.7s -O3
28.0s -O3 -fno-crossjumping
37.6s -Os
35.4s -Os -fno-crossjumping
The above *strongly* suggest that -fcrossjumping is pessimistic, at
least in the case of huffbench. I dislike basing a broad assumption on a
single test instance; I have yet to run complete tests on the other four
benchmarks in my suite, and when I do, I'll be able to make a broader
statement.
As for my Acovea-evolved set of options:
22.3s -O1 -fno-crossjumping -fexpensive-optimizations \
-fregmove -freorder-blocks -frename-registers \
-fnew-ra -funroll-all-loops -fomit-frame-pointer
I'm running gcc 3.4 20031119.
The performance of my evolved option set was rather impressive -- 27%
*faster* than -O3 alone.
My first guess was that the "-fnew-ra -funroll-all-loops
-fomit-frame-pointer" options (not included in -O3) were primarily
responsible for improved performance. So I tried these two tests:
32.4s -O3 -fnew-ra -funroll-all-loops -fomit-frame-pointer
32.6s -O3 -fno-crossjumping \
-fnew-ra -funroll-all-loops -fomit-frame-pointer
My guess was onbviously *wrong.* Sooo.... to me, the above results
suggest a pessimistic interaction among options implied by -O1/2/3.
Crossjumping is not supposed to get code faster, it is code size
optimization, so the -O3 difference is likely showing that your code
is getting off the caches. Said that, it seems to me that it is good
optimization for -O2 becuase binary size is very important factor.
According to the docs, -fcrossjumping is enabled with both -O1 and -Os.
It seems to me that -fcrossjumping should *only* be implied by -Os, not
-O1, given that -Os implies optimization for size, and -O1/2/3 imply
optimization for speed.
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing