Live data from Hacker News

What Are Your GCC Flags?

blog.httrack.com

81–90 of 117 posts

Re: What Are Your GCC Flags?

#81
post #76

Earlier quoted context omitted.

1. -fomit-frame-pointer is implied by O3 on most platforms now 2. "too likely to cause harm, too unlikely to make a significant performance difference in most cases." Please define "most cases". Without this, GCC will have significant trouble being able to derive the bounds of most loops, and in turn, will not be able to vectorize, unroll, peel, split, etc. Saying "unlikely to make a significant performance different…

1. that's good to know. I'm all for shortening my cflags line since I don't squelch my Makefile rules. 2. I always get bitten when I try and generalize. I tested this in all of my software, and was not able to detect any performance difference with or without -fwrapv (that is to say, I know you can create extreme edge cases where there's a huge difference, just as you can probably make up one that's slower without -f…

2. You must not write software very amenable.

Fun fact btw: GCC and LLVM are the only compilers I know of to assume loops can overflow at all when optimizations are on.

Compilers like XLC will actually even assume unsigned loop induction variables will not ovefrlow at O3, unless you give them special flags.

:)

Re: What Are Your GCC Flags?

#82
post #25

The compiler flags for Ag[1] are rather strict these days: -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow \ -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces \ -std=gnu89 -D_GNU_SOURCE -O2 Note that -Wall and -Wextra do not enable all warnings. To keep backwards compatibility, -Wall is basically, "All warnings as of 1990." -Wextra covers a lot of the newer warnings, but still misses a few…

I really wish for a -Weverything flags that would enable all warnings, even the stupid, useless ones. I'd then put -Wno- to disable those.

clang has -Weverything, I prefer to start with that and do #pragma clang diagnostic push/ignored/pop as needed and only turn off the really obnoxious ones, like -W-c++98-compat-pedantic

Re: What Are Your GCC Flags?

#83
Most of these are clang specific but I tend to do something like

-pipe

-std=c++11

-gfull # generate correct debugging symbols for dead code stripping

-stdlib=libc++

-Ofast # fast, aggressive optimizations (clang-specific)

-fvectorize # enable loop autovectorizer

-fdiagnostics-show-template-tree (clang: print C++ template error as a tree instead of on a single line)

-Weverything # clang specific: enable every single warning

-Werror

-Wfatal-errors # die after the first error encountered

-Wno-c++98-compat

-Wno-c++98-compat-pedantic

-Wno-global-constructors

-Wno-exit-time-destructors

-ffast-math # enable some floating point optimizations that break IEEE754 compliance but usually work

-funroll-loops # enable loop unrolling

-fstrict-aliasing # make more aggressive assumptions about whether pointers can point to the same objects

-fatal_warnings # treat linker warnings as fatal

-flto # enable link-time optimization

-dead_strip # enable dead code stripping

-Wno-error=deprecated # like being able to put __attribute((deprecated)) in code as a note to self

-Wno-error=#warnings # same thing goes for #warnings

Re: What Are Your GCC Flags?

#84
post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant one. The problem, of course, is that it destroys the ability to examine performance in production with tools like DTrace and the like. A one-time couple-of-percent improvement in some cases (which, again, would be surprising to see anyway) is not worth losing the ability to gain more performance improvements for the rest of the software's lifetime.

Re: What Are Your GCC Flags?

#85

"-Winit-self" actually disables the common "var x = x" idiom which is used to silence "uninitialized variable" warnings. Personally I consider "-Werror" stupid. Warnings are designed to help and be reviewed, but aiming at "100% warning free" code should not be an "aim". For instance, I'd rather have "unitialized warnings" than use "i = i", which you know, might actually be correct code if "i" was available in scope a…

If you're using var x = x; then stop. The compiler is able to validate that assignment to variables are never used using data flow analysis, so always initializing has no cost once optimizations are turned on. Beside, even if it was not optimized away, until a profiler actualy shows that a variable initialization is your bottleneck, it's a waste of time and will make code refactoring harder and cuase bug down the line. Maybe not in this function, maybe not by you, but someone will add a new conditional branch somewhere where your variable won't be initialized.

As for the optimization, I just tested on my machine:

   int main(int argc, char** argv)
   {
      int x = 0;

      switch (argc)
      {
         case 0:
            x = 1;
            break;
         case 1:
            x = 5;
            break;
         case 2:
            x = 7;
            break;
         default:
            x = 9;
            break;
      }

      return x;
   }

   gcc -O3 -o opt-assign opt-assign.c

   (gdb) disassemble main
Showed that x is never assigned zero.

Re: What Are Your GCC Flags?

#87
Firefox's about:buildconfig page will tell you the compiler flags used to compile your Firefox:

  clang++ -Qunused-arguments -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual
  -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body
  -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof
  -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags
  -Wno-error=uninitialized -Wno-error=deprecated-declarations -isysroot /Developer/
  SDKs/MacOSX10.6.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections
  -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNO_X11 -pipe
  -DNDEBUG -DTRIMMED -g -O3 -fno-omit-frame-pointer -Qunused-arguments

Re: What Are Your GCC Flags?

#88
post #84
post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant one. The problem, of course, is that it destroys the ability to examine performance in production with tools like DTrace and the like. A one-time couple-of-percent improvement in some cases (…

It was very beneficial on the register-starved x86, but I notice less impact on amd64.

I definitely also have a debug-mode that builds with -g and without -s -O3 -fomit-frame-pointer.

Re: What Are Your GCC Flags?

#90
I start with:

    -Os
I really don't like the stack protector. It adds a lot of space to executables, so I turn it off:

    -fno-stack-protector
Arthur told me about:

    -fno-asynchronous-unwind-tables
which seems to save a lot of space. I don't know exactly what it does, but the documentation suggests it does something with debugging, however `-s` doesn't remove it so I have this here.

I often work without glibc (don't need it) but I like gcc's builtins so I have:

    -Dabort=__builtin_trap -Dmemcpy=__builtin_memcpy -Dmemset=__builtin_memset -minline-all-stringops -msse2 -ffreestanding -nostdlib -fno-builtin
which seems to do the trick. I don't think all of these are necessary on all versions of GCC but I keep running into versions that complain about something so this line keeps getting longer. On x86 I additionally use:

    -mregparm=3
since it saves a lot of space and helps benchmarks.
Post reply on HN