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:
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.
I'll do so in the next day or so; right now, I'm running baselines for
the other benchmarks.
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.
So perhaps we need a -Oint and -Ofloat (or better, -Oengine) options? I
do not think we should pessimize engine code -- databases, codecs,
servers -- by favoring only the needs of interactive and script code (or
vice versa!)
The vast majority of developers lack the time and knowledge required to
define specific sets of optimizations for their programs; they will use
-O2 under the (I think valid) assumption that it produces faster code
than does -O1. And the existence of -Os (which explicitly optimizes for
"size") implies that -O1/2/3 optimize for speed.
In fact I think we should have -Ofast/-Osize pair for users who want
such a specialzed one way tunning.
A -Ofast1 and -Ofast2 could define different sets of switches known to
produce fast code. Different pieces of code require different
optimizations; what may optimize one algorithm may pessimize another.
I'm working on a real-time video codec for a customer; it is *very*
significant that I can improve the program's speed, with evolved
options, by 25% or more over GCC's default optimization options.
Wanting the fastest possible generated code is *not* a "specialized way
of tuning." I find the "speed doesn't matter" attitude rather
disturbing; it is part-and-parcel to the code-bloat now considered
"acceptable" by a wide segment of the programming community. The best
program is defined by the combination of efficient algorithms *and*
effective code generation.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing
In development: Alex, a database for common folk