This is the mail archive of the 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: RFC: Improving GCC8 default option settings

> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool <> wrote:
> On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
>>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
>>> mentioned repeatedly) which GCC could/should do as well.
>> There are some nuances to -O2. Please consider -O2 users who wish use it like Clang/LLVM’s -Os (-O2 without loop vectorisation IIRC).
>> Clang/LLVM has an -Os that is like -O2 so adding optimisations that increase code size can be skipped from -Os without drastically effecting performance.
>> This is not the case with GCC where -Os is a size at all costs optimisation mode. GCC users option for size not at the expense of speed is to use -O2.
> "Size not at the expense of speed" exists in neither compiler.  Just the
> tradeoffs are different between GCC and LLVM.  It would be a silly
> optimisation target -- it's exactly the same as just "speed"!  Unless
> “speed" means "let's make it faster, and bigger just because" ;-)

I would like to be able to quantify stats on a well known benchmark suite, say SPECint 2006 or SPECint 2017 but in my own small benchmark suite I saw a disproportionate difference in size between -O2 and -Os, but a significant drop in performance with -O2 vs -Os.


-O2 is 98% perf of -O3 on x86-64
-Os is 81% perf of -O3 on x86-64

-O2 saves 5% space on -O3 on x86-64
-Os saves 8% space on -Os on x86-64

17% drop in performance for 3% saving in space is not a good trade for a “general” size optimisation. It’s more like executable compression.

-O2 seems to be a suite spot for size versus speed.

I could only recommend GCC’s -Os if the user is trying to squeeze something down to fit the last few bytes of a ROM and -Oz seems like a more appropriate name.

-O2 the current suite spot in GCC and is likely closest in semantics to LLVM/Clang -Os and I’d like -O2 binaries to stay lean.

I don’t think O2 should slow down nor should the binariesget larger. Turning up knobs that effect code size should be reserved for -O3 until GCC makes a distinction between -O2/-O2s and -Os/-Oz.

On RISC-V I believe we could shrink binaries at -O2 further with no sacrifice in performance, perhaps with a performance improvement by reducing icache bandwidth…

BTW -O2 gets great compression and performance improvements compared to -O0 ;-D it’s the points after -O2 where the trade offs don’t correlate.

I like -O2

My 2c.

> GCC's -Os is not "size at all costs" either; there are many options (mostly
> --params) that can decrease code size significantly.  To tune code size
> down for your particular program you have to play with options a bit.  This
> shouldn't be news to anyone.
> '-Os'
>     Optimize for size.  '-Os' enables all '-O2' optimizations that do
>     not typically increase code size.  It also performs further
>     optimizations designed to reduce code size.
>> So if adding optimisations to -O2 that increase code size, please considering adding an -O2s that maintains the compact code size of -O2. -O2 generates pretty compact code as many performance optimisations tend to reduce code size, or otherwise add optimisations that increase code size to -O3. Adding loop unrolling on makes sense in the Clang/LLVM context where they have a compact code model with good performance i.e. -Os. In GCC this is -O2.
>> So if you want to enable more optimisations at -O2, please copy -O2 optimisations to -O2s or rename -Os to -Oz and copy -O2 optimisation defaults to a new -Os.
> '-O2'
>     Optimize even more.  GCC performs nearly all supported
>     optimizations that do not involve a space-speed tradeoff.  As
>     compared to '-O', this option increases both compilation time and
>     the performance of the generated code.
>> The present reality is that any project that wishes to optimize for size at all costs will need to run a configure test for -Oz, and then fall back to -Os, given the current disparity between Clang/LLVM and GCC flags here.
> The present reality is that any project that wishes to support both GCC and
> LLVM needs to do configure tests, because LLVM chose to do many things
> differently (sometimes unavoidably).  If GCC would change some options
> to be more like LLVM, all users only ever using GCC would be affected,
> while all other incompatibilities would remain.  Not a good tradeoff at
> all.
> Segher

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