[Bug other/53316] New: Change -O1 to be easily debugged and on by default

[Bug other/53316] New: Change -O1 to be easily debugged and on by default

[DeusExSophismata at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

             Bug #: 53316
           Summary: Change -O1 to be easily debugged and on by default
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: DeusExSophismata@gmail.com


The definition of -O1 is currently based on optimizations that are quick to do
(focused on minimizing compile time). However, in the -Wall by default thread,
people discussed changing the semantics / defaults of optimization.

http://gcc.gnu.org/ml/gcc/2012-04/msg00134.html

In particular, this post was interesting:
http://gcc.gnu.org/ml/gcc/2012-04/msg00181.html

The suggestion is to change -O1 to instead be optimizations that do not
interfere with debugging. I was especially interested in the claim by Richard
Guenther: "I'd expect compile time that should be better or at least not a lot
slower than -O0". Basically, that a few optimizations that remove some of the
cruft from code could actually speed up later stages of compilation, so we
could get faster programs that also compile faster (or at the very least, at a
similar speed). This would make it easier to debug applications that rely on
optimizations to run at reasonable speeds. -O2 and -O3 could maintain their
current definition.

It would then be possible to turn this on by default with few (if any) negative
consequences, because debugging is not impaired, compile-time likely won't be
increased by much (if at all), and run-time performance will be improved. This
would also improve the effectiveness of certain warnings.

Robert Dewar proposed a two-phase approach. First, we create a new,
experimental optimization level to see if we actually can find a set of
optimizations that do not interfere with debugging and do not significantly
slow compilation. Then we change O1 to mean this optimization level. This way
we are separating production levels from experimental levels. We could
temporarily call the new level something like -Odebug or -Og.

As it stands, does anyone even use -O1? It seems like it would be a major
improvement to make it useful.

[Bug other/53316] Change -O1 to be easily debugged and on by default

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-10 23:13:17 UTC ---
I think this is not a good idea ....

[Bug other/53316] Change -O1 to be easily debugged and on by default

[DeusExSophismata at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

David Stone <DeusExSophismata at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |DeusExSophismata at gmail
                   |                            |dot com

--- Comment #2 from David Stone <DeusExSophismata at gmail dot com> 2012-05-10 23:28:57 UTC ---
(In reply to comment #1)
> I think this is not a good idea ....

I think I explained the potential gains already. What are the potential harms?
Why is it not a good idea?

[Bug other/53316] Change -O1 to be easily debugged and on by default

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-11 05:34:19 UTC ---
Changing the default from -O0 to -O1?  Obviously huge amount of code in the
wild that expects that -O0 is the default, which has been the case for the last
25 years.  The advantages are nil.

[Bug other/53316] Change -O1 to be easily debugged and on by default

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-05-11 06:07:42 UTC ---
> 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.

[Bug other/53316] Introduce -Odebug

[rguenth at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[david at doublewise dot net]

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.

[Bug other/53316] Introduce -Odebug

[david at doublewise dot net]

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

[rguenth at gcc dot gnu.org]

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=gcc&view=rev&rev=191464
Log:
2012-09-19  Richard Guenther  <rguenther@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

[rguenth at gcc dot gnu.org]

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=gcc&view=rev&rev=191465
Log:
2012-09-19  Richard Guenther  <rguenther@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 -Og

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53316

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.0
            Summary|Introduce -Odebug           |Introduce -Og

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-19 09:33:02 UTC ---
Fixed.