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 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" ;-)

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.

     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.

     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


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