Add a new optimization option -Og

[sylvestre.ledru]

Summary

Just like gcc, we should have the -Og option as more and more software are using it:
https://llvm.org/bugs/show_bug.cgi?id=20765

[majnemer]

Please include full context with your diff.

lib/Frontend/CompilerInvocation.cpp

101–103

Please clang-format this.

[sylvestre.ledru]

with the full context + clang format

[rengolin]

Hi Sylvestre,

Paul's comments on the bug are still pertinent: -Og is not the same as -O1.

-Og means for "optimised for debuggers" which is short for "preserve the debug illusion without bloating the code". This is not at all what -O1 is, even though they're used indistinguishably via -O1 -g.

As a stop-gap, I guess having -Og == -O1 would stop errors from being reported, but if we could do a quick assessment on the list to make sure this has the expected semantics (and adding a full new option if not), would be the best way forward.

I'm adding a few debug folks here, in hope they have a better idea (and would add more folks, if necessary). :)

cheers,
--renato

[dblaikie]

test/Driver/debug-options.c

21–22 ↗

(On Diff #72759)

I don't think we need this test case: -Og doesn't actually have anything to do with -g mechanically speaking, so there's no need to test them together.

I'd probably go find wherever -O1 is tested in the driver, and test -Og there.

[probinson]

As Renato points out, this addresses the user experience of tripping over the lack of -Og, however it does not really address the intent of PR20765 which is to provide a mode of optimizations that don't particularly interfere with debugging.
Eventually someone needs to take on the project of "proper -Og" which might or might not result in -Og still matching -O1.
I am not opposed to starting out this way, but don't close the PR.

If we later get user complaints about how -Og interferes with debugging, well, then we'll have actual use-cases to work from, which is extremely helpful for this sort of optimization tuning.

test/Preprocessor/init.c

208

check-prefix O1? Then you don't need the Og: and Og-NOT: lines.

[keith.walker.arm]

Looking into what optimisations would be relevant to -Og (or rather what optimisation should be omitted because they are too disruptive to the debug experience) is something that I have on my road-map as something to look into and gather feedback on.

I agree that this should be considered as just the starting point for enabling a fully functional -Og option.

[rengolin]

I agree with Keith. This is a starting point, not a final destination.

As we evolve this, we can start looking at better ways to improve the debug illusion, but right now, O1 is probably the best thing to do.

LGTM, thanks!

[torarnv]

This seems to have hit a recent Xcode toolchain (Xcode 9.1 ?).

Xcode now complains that "[app name] was compiled with optimization - stepping may behave oddly; variables may not be available.", when launching a debug session, which seems to be the case, debugging is all over the place :)

Reproduced on both macOS and iOS targets.

See https://codereview.qt-project.org/#/c/212142/

[aprantl]

In D24998#932061, @torarnv wrote:

This seems to have hit a recent Xcode toolchain (Xcode 9.1 ?).

Xcode now complains that "[app name] was compiled with optimization - stepping may behave oddly; variables may not be available.", when launching a debug session, which seems to be the case, debugging is all over the place :)

LLDB prints this warning whenever LLVM marks a compile unit with DW_AT_optimized (which LLVM does for everything but -O0).

Reproduced on both macOS and iOS targets.

See https://codereview.qt-project.org/#/c/212142/

docs/CommandGuide/clang.rst

.. option:: -march=<cpu>
   member and later.  For example, if you specify -march=i486, the compiler is
   allowed to generate instructions that are valid on i486 and later processors,
   but which may not exist on earlier ones.
 
 
 Code Generation Options
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-.. option:: -O0, -O1, -O2, -O3, -Ofast, -Os, -Oz, -O, -O4
+.. option:: -O0, -O1, -O2, -O3, -Ofast, -Os, -Oz, -Og, -O, -O4
 
   Specify which optimization level to use:
 
     :option:`-O0` Means "no optimization": this level compiles the fastest and
     generates the most debuggable code.
 
     :option:`-O1` Somewhere between :option:`-O0` and :option:`-O2`.
 
Specify which optimization level to use:
     language standards.
 
     :option:`-Os` Like :option:`-O2` with extra optimizations to reduce code
     size.
 
     :option:`-Oz` Like :option:`-Os` (and thus :option:`-O2`), but reduces code
     size further.
 
+    :option:`-Og` Like :option:`-O1`. In future versions, this option might 
+    disable different optimizations in order to improve debuggability.
+
     :option:`-O` Equivalent to :option:`-O2`.
 
     :option:`-O4` and higher
 
       Currently equivalent to :option:`-O3`
 
 .. option:: -g, -gline-tables-only, -gmodules
 

lib/Frontend/CompilerInvocation.cpp

if (A->getOption().matches(options::OPT_Ofast))
       return 3;
 
     assert (A->getOption().matches(options::OPT_O));
 
     StringRef S(A->getValue());
     if (S == "s" || S == "z" || S.empty())
       return 2;
 
+    if (S == "g")
+      return 1;
+
     return getLastArgIntValue(Args, OPT_O, DefaultOpt, Diags);
   }
 
   return DefaultOpt;
 }
 
 static unsigned getOptimizationLevelSize(ArgList &Args) {
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {

test/Preprocessor/init.c

 //
 //
 // RUN: %clang_cc1 -O1 -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix O1 %s
 //
 // O1-NOT:#define __OPTIMIZE_SIZE__
 // O1:#define __OPTIMIZE__ 1
 //
 //
+// RUN: %clang_cc1 -Og -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix Og %s
+//
+// Og-NOT:#define __OPTIMIZE_SIZE__
+// Og :#define __OPTIMIZE__ 1
+//
+//
 // RUN: %clang_cc1 -Os -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix Os %s
 //
 // Os:#define __OPTIMIZE_SIZE__ 1
 // Os:#define __OPTIMIZE__ 1
 //
 //
 // RUN: %clang_cc1 -Oz -E -dM < /dev/null | FileCheck -match-full-lines -check-prefix Oz %s
 //