Re: Should -fcross-jumping be part of -O1?

[Jan Hubicka <jh at suse dot cz>]

> 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.
Because there was no way to disable it.
I've added -fcrossjumping because of the compilation time issues we was
running into.  The issues are solved now.
> 
> 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
Please do.  The control flow changes do have very random effect on
modern x86 CPUs because of the complexity involved in the instruction
decoding stages.
Can you please also try profile feedback?  It is well possible the
compiler is misspredicting something resulting in randomly suboptimzal
code layout.
> 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
> 
> 
> >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.
No, -O2 is supposed to be generally usefull option so it can not produce
unnecesairly big binaries.  When running common integer code (startup
scripts, KDE, OpenOffice, Gnome, whatever normal users are supposed to
run today), code size is very critical. Both code size and speed should
be in balance.
In fact I think we should have -Ofast/-Osize pair for users who want
such a specialzed one way tunning.

Honza
> 
> -- 
> Scott Robert Ladd
> Coyote Gulch Productions (http://www.coyotegulch.com)
> Software Invention for High-Performance Computing