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 Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra <> wrote:
> Hi all,
> At the GNU Cauldron I was inspired by several interesting talks about improving
> GCC in various ways. While GCC has many great optimizations, a common theme is
> that its default settings are rather conservative. As a result users are
> required to enable several additional optimizations by hand to get good code.
> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
> mentioned repeatedly) which GCC could/should do as well.
> Here are a few concrete proposals to improve GCC's option settings which will
> enable better code generation for most targets:
> * Make -fno-math-errno the default - this mostly affects the code generated for
>   sqrt, which should be treated just like floating point division and not set
>   errno by default (unless you explicitly select C89 mode).

+1. Math functions setting errno is a blast from the past that needs
to die. That being said, this does to some extent depend on libm so
perhaps the default needs to be target-dependent.

> * Make -fno-trapping-math the default - another obvious one. From the docs:
>   "Compile code assuming that floating-point operations cannot generate
>    user-visible traps."
>   There isn't a lot of code that actually uses user-visible traps (if any -
>   many CPUs don't even support user traps as it's an optional IEEE feature).
>   So assuming trapping math by default is way too conservative since there is
>   no obvious benefit to users.

As Mr. Myers explains, this is probably going a bit too far. I think
by default whatever fp optimizations are allowed with FENV_ACCESS off
is reasonable.

> * Make -fomit-frame-pointer the default - various targets already do this at
>   higher optimization levels, but this could easily be done for all targets.
>   Frame pointers haven't been needed for debugging for decades, however if there
>   are still good reasons to keep it enabled with -O0 or -O1 (I can't think of any
>   unless it is for last-resort backtrace when there is no unwind info at a crash),
>   we could just disable the frame pointer from -O2 onwards.

Sounds reasonable.

> These are just a few ideas to start. What do people think? I'd welcome discussion
> and other proposals for similar improvements.

What about the default behavior if no options are given? I think a
more reasonable default would be something roughly like

-O2 -Wall

or if debuggability is considered more important that speed & size, maybe

-Og -g -Wall

Janne Blomqvist

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