[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-19 09:30:03 UTC --- Author: rguenth Date: Wed Sep 19 09:29:57 2012 New Revision: 191464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191464 Log: 2012-09-19 Richard Guenther rguent...@suse.de PR other/53316 * common.opt (optimize_debug): New variable. (Og): New optimization level. * doc/invoke.texi (Og): Document. * opts.c (maybe_default_option): Add debug parameter. (maybe_default_options): Likewise. (default_options_optimization): Handle -Og. (common_handle_option): Likewise. * passes.c (gate_all_optimizations): Do not run with -Og. (gate_all_optimizations_g): New gate, run with -Og. (pass_all_optimizations_g): New container pass, run with -Og. (init_optimization_passes): Schedule pass_all_optimizations_g alongside pass_all_optimizations. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/opts.c trunk/gcc/passes.c
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-19 09:31:53 UTC --- Author: rguenth Date: Wed Sep 19 09:31:49 2012 New Revision: 191465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191465 Log: 2012-09-19 Richard Guenther rguent...@suse.de PR other/53316 * common/common-target.h (OPT_LEVELS_1_PLUS_NOT_DEBUG): Add. Modified: trunk/gcc/ChangeLog trunk/gcc/common/common-target.h
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #10 from David Stone david at doublewise dot net 2012-05-16 15:57:13 UTC --- I did some research to see how often each optimization level is actually used. Looking solely at the most followed C and C++ repositories on github, I collected the following data: C: Linux kernel: 2 s redis: 2 0 vim: 2 6 0 (6 and 0 for commented out options that are selectively enabled for testing) git: 2 s 0 (s for debugging, 0 for code coverage tests) PHP: 0 2 s openFrameworks: s memcached: no defaults found (somewhat thorough check, autotools) libfreenect: 2 xbmc: 2 mruby: 3 (even for debugging!) wax: no defaults found (rake) beanstalkd: use the default 0 (implicit, Make) ccv: 1 (but they preceed it with CC = clang, so it's not really relevant for us) yajl-ruby: no defaults found (rake) libgit2: 2 0 iProxy: seems to be XCode only http-parser: 0 3 nginx_http_push_module: no build scripts, so no defaults C++: hiphop-php: 0 3 s MongoDB: 0 3 Doom GPL: 0 1 3 (0 and 1 are both used with debugging) PhantomJS: no defaults found (qmake) MaNGOS: Does not appear to set (thorough check, CMake) Scribe: 3 0 TrinityCore: Does not appear to set any optimization level, but does turn on some 'f' flags specifically (CMake) bitcoin: 2 firesheep: 0 Mosh: 2 farbrausch/fr_public: Written for Visual Studio twitter/MySQL: 0 3 Cinder: (uses XCode 3.2 on Mac, Visual C++ on Windows) therubyracer: no defaults found (rake) wkhtmltopdf: no defaults found (qmake) v8: 0 3 2 (the 2 seems to be always added after the 3, so I don't know if the 3 is actually ever used) depthjs: no defaults found (CMake) node-canvas: 3 libzmq: 0 HandlerSocket: 3 I think it's interesting to note that -O1 only appears a single time, and that is in the Doom 3 source. -O0 and -O1 are both used for debugging, with -O3 used for release. -O0 shows up 16 times for sure (plus possibly some implicit -O0), -O2 shows up 11 times, -O3 shows up 10 times (although I believe it is overwritten with -O2 in one of them), and -Os shows up 5 times. -Os is used 4 times in C code compared to just once in C++. However, -O3 is used 8 times in C++, compared to only twice in C. In general, C projects seem to prefer -O2, while C++ projects seem to prefer -O3. I could not find a default optimization setting for 11 out of 34 projects (+ 4 that definitely do not use gcc). Of those 11 projects: * 1 has no build scripts at all (and thus the default is just whatever the compiler default is, therefore -O0) * 2 use qmake, which I believe can be called with something like -release, which gets -O3, but defaults to -O0 (I'm not sure on this, I don't use qmake) * 3 use rake, which may set its own defaults (I don't know). I couldn't find a single default for projects using rake. * 3 use CMake, which may set its own defaults (I don't know) * 1 uses a plain Makefile, and I believe I checked everything and could not find any defaults (so I counted it as -O0) * 1 uses the auto-tools, and I checked pretty thoroughly and I could not find any default settings, but there is a slight chance I may have missed it so I didn't count it as -O0
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-11 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Summary|Change -O1 to be easily |Introduce -Odebug |debugged and on by default | Ever Confirmed|0 |1 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:38:41 UTC --- (In reply to comment #4) As it stands, does anyone even use -O1? It seems like it would be a major improvement to make it useful. Of course people do use -O1 and making such an incompatible change to it is out of question I think. That's largely orthogonal to introducing -Odebug (and making it the default) in my opinion. Of course people should realize that -O1 is by no means maintained as in tuned in any way to do something reasonable. At the moment it wastes much time for no good reason, just selectively turning off some optimizations. Re-tuning -O1 definitely makes sense - maybe not to the point we'd want to go with -Odebug. I'm taking this bug as a request to add -Odebug, something I was working on, so - mine.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-11 08:52:51 UTC --- A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:56:41 UTC --- (In reply to comment #6) A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues. Well, -Odebug should aid debugging, so yes, we should enable var-tracking for it (we can throttle the limiting --params more if compile-time is going to be an issue). Of course we should evaluate the actual benefit of var-tracking for -Odebug when it materializes.
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-11 08:58:23 UTC --- (In reply to comment #7) (In reply to comment #6) A big question for -Odebug is e.g. if we should enable var-tracking for it or not. While it is time consuming, it should improve the debug experience, there are various cases where -O -g is actually better debuggable than -O0 -g which doesn't do var-tracking, e.g. with register vars, or VLAs, or during prologues/epilogues. Well, -Odebug should aid debugging, so yes, we should enable var-tracking for it (we can throttle the limiting --params more if compile-time is going to be an issue). Of course we should evaluate the actual benefit of var-tracking for -Odebug when it materializes. Btw, my personal goal is to make -Odebug a good default for my GCC development tree (which currently sits at -O0 -g) - I suppose for that particular case var-tracking isn't that important, but I will definitely notice if there is a difference ;)
[Bug other/53316] Introduce -Odebug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316 --- Comment #9 from David Stone david at doublewise dot net 2012-05-11 15:48:53 UTC --- I suppose this is a much better way to phrase the suggestion as a starting point. First get -Odebug and then see where we go from there.
