This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Improving GCC8 default option settings
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Wed, 13 Sep 2017 10:43:42 +0300
- Subject: Re: RFC: Improving GCC8 default option settings
- Authentication-results: sourceware.org; auth=none
- References: <HE1PR0801MB2058CFEE6A9C43380337A83F83690@HE1PR0801MB2058.eurprd08.prod.outlook.com>
On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> 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
> * 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.
> 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
or if debuggability is considered more important that speed & size, maybe
-Og -g -Wall