public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/53316] New: Change -O1 to be easily debugged and on by default
@ 2012-05-10 23:13 DeusExSophismata at gmail dot com
  2012-05-10 23:18 ` [Bug other/53316] " pinskia at gcc dot gnu.org
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: DeusExSophismata at gmail dot com @ 2012-05-10 23:13 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-09-19  9:33 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-10 23:13 [Bug other/53316] New: Change -O1 to be easily debugged and on by default DeusExSophismata at gmail dot com
2012-05-10 23:18 ` [Bug other/53316] " pinskia at gcc dot gnu.org
2012-05-10 23:32 ` DeusExSophismata at gmail dot com
2012-05-11  5:57 ` jakub at gcc dot gnu.org
2012-05-11  6:27 ` ebotcazou at gcc dot gnu.org
2012-05-11  8:41 ` [Bug other/53316] Introduce -Odebug rguenth at gcc dot gnu.org
2012-05-11  8:55 ` jakub at gcc dot gnu.org
2012-05-11  9:01 ` rguenth at gcc dot gnu.org
2012-05-11  9:01 ` rguenth at gcc dot gnu.org
2012-05-11 15:52 ` david at doublewise dot net
2012-05-16 16:15 ` david at doublewise dot net
2012-09-19  9:30 ` rguenth at gcc dot gnu.org
2012-09-19  9:32 ` rguenth at gcc dot gnu.org
2012-09-19  9:33 ` [Bug other/53316] Introduce -Og rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).