This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Improving GCC8 default option settings
> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool <segher@kernel.crashing.org> 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.
- https://rv8.io/bench#optimisation
- https://rv8.io/bench#executable-file-sizes
-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