Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Are Your GCC Flags?

blog.httrack.com

Post reply on HN
Print view View original

71–80 of 117 posts

Re: What Are Your GCC Flags?

#71

Post by DannyBee »

sanxiyn wrote: post #11

The article does not mention optimization, but standard optimization levels (-O1, -O2, -O3) are not chosen optimally at all. See http://dl.acm.org/citation.cfm?id=1356080 For tuning GCC flags for a particular application, see http://opentuner.org/

" are not chosen optimally at all"

Optimally is kind of a non-sensical term for this. There is no optimality to be found here in any mathematical sense. Even COLE does not generate optimal, it finds something mildly reasonable.

However, the main problem with things like COLE, is that they mostly discover phase ordering issues or latent optimization bugs. Those are bugs and problems that should be fixed.

Most of phase ordering is decided by design and architecture, ie "we want it to work a certain way for certain reasons". To the degree it doesn't work best that way, it's usually a problem to be fixed, not a fundamental issue that COLE has discovered.

Re: What Are Your GCC Flags?

#72

Post by xroche »

simula67 wrote: post #26
xroche wrote: post #19

Earlier quoted context omitted.

Our experience is that it is actually an excellent sanitary decision. We are using multiple builders with fixed GCC releases (for RHEL5, RHEL6 etc. flavors), and yes it means fixing additional warnings when we have to introduce a new architecture. But I can not count the number of serious issues we avoided by spotting and investigating warnings.

Hi Xavier Kinda off-topic, but have you considered translating HTTrack comments and variable names to English ?

Hmmm, to be honest I wish I had the time, and more than that, the courage, to cleanup the code (and this would include major refactoring and redesign). The project is now 15 years old (D'oh!), and was not aimed to live more than six months at that time, leading to an awfully bad overall coding style.

Re: What Are Your GCC Flags?

#73

Post by DannyBee »

fexl wrote: post #40
sanxiyn wrote: post #38

Earlier quoted context omitted.

Why don't you use -O2 -finline-functions then?

Good question. I go with -O3 because it does even more optimizations, but to be quite candid I really don't know what impact -fpredictive-commoning, -ftree-vectorize, and others have on my resulting machine code, if any. I did a quick experiment, compiling one C file with -O2 -finline-functions and another with -O3, using the -S flag so I could see the assembler output. The only difference I saw was this: .comm free_…

predictive commoning is a loop optimization that commons cross-loop redundancies.

It is basically CSE "around loops". You can generalize it to subsume loop store motion and strength reduction, but most compilers (including GCC) don't bother.

For example, it transforms

  for (int i = 0; i
into

  p0 = a[0]
  p1 = a[1]
  for (int i = 0; i
Eliminating a whole ton of loads and stores.

It's been a while since i looked at GCC's implementation, but it did pretty well in the past (whether you can do commoning depends on your ability to identify and group sequences, etc)

-ftree-vectorize does the obvious thing (turn on vectorization). How effective it is depends on a lot of factors.

Re: What Are Your GCC Flags?

#74

Post by xroche »

taspeotis wrote: post #4

-fno-exceptions I don’t like C++ exceptions. And we don’t use them where I work And none of your code uses the STL nor third party libraries that might throw exceptions either, right [1] [1] "Doing without" http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_excepti...

AFAIK, stl (and beyond that, C++) throw exceptions especially in case of allocation failure (ie. new or push_back() failing to allocate memory), and more generally in case of programming errors (out_of_range, bad_cast etc.), and I am 100% okay with the program aborting() in such situation.

Re: What Are Your GCC Flags?

#75

Post by stusmall »

near wrote: 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…

Why would you want to switch on a boolean statement?

EDIT: Ignore me. I see your explanation below.

Re: What Are Your GCC Flags?

#76

Post by byuu »

DannyBee wrote: post #70
near wrote: 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…

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 -fwrapv if you really wanted to.

But yeah, maybe I just don't write code that lends itself to benefiting heavily from these types of assumptions. I also tend to not really rely on signed integer overflow following twos-complement. But all the same, I will take well-defined behavior over the crazy stuff GCC can produce any day, even at the cost of a bit of performance. Of course, going all the way to -O0 is way too extreme. So a case where I see no perceptible performance impact and gain defined behavior? Win-win.

Re: What Are Your GCC Flags?

#77

Post by psquid »

dllthomas wrote: post #58

I recommend -Wswitch-default and -Wswitch-enum. Without these, you're stuck choosing between foregoing safety when a bug causes an enum to take an unexpected value, and foregoing safety when you add a new value to an enum that needs to be handled in many places.

Oh hey, that's pretty nice! I'm a big fan of how the functional languages I've gone further than dabbling in are very pushy about covering all cases for pattern matches (basically switch on steroids), even if sometimes the correct answer is to just throw in a catch-all.

Mostly because it forces you upfront to make sure you're considering every case, and it looks like those warnings ought to give me the same kind of nagging with C and enums.

Re: What Are Your GCC Flags?

#78

Post by saosebastiao »

ggreer wrote: 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…

Upvote for the completely off-topic reason of having written one of the most amazingly useful tools I have ever touched.

Re: What Are Your GCC Flags?

#79

Post by detrino »

DannyBee wrote: post #70
near wrote: 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…

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…

I'm curious if there is a way to rewrite your loops which use unsigned types to somehow communicate to the compiler that you will not overflow.

Re: What Are Your GCC Flags?

#80

Post by DannyBee »

detrino wrote: post #79
DannyBee wrote: post #70

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…

I'm curious if there is a way to rewrite your loops which use unsigned types to somehow communicate to the compiler that you will not overflow.

You'd have to use annotations or asserts. Or rely on literal whole program analysis to prove upper bounds of parameters/etc (which still may not be possible statically)

Otherwise, given as something as simple as

for (unsigned i = 0; i You can't say it iterates N/2 times

Post reply on HN