On Tue, Sep 12, 2017 at 4:57 PM, Wilco Dijkstra <wilco.dijks...@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 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
