-Og includes inlining optimizations harmful to debugging since 13.0

[jeremy-murphy]

Clang 13.0 started to inline functions at -Og, which my colleagues consider makes debugging near impossible.
See this Godbolt for a comparison of 12.0, 13.0 and GCC 13.2: https://godbolt.org/z/WWq75G353

The release notes for 13.0 don't mention anything that leaps out to me as an explanation.

[EugeneZelenko]

Could you please try 17 Release Candidate or main branch? https://godbolt.org should be helpful.

[aeubanks]

Right now -Og is equivalent to -O1. I suspect that the change from the legacy to new pass manager for the optimization pipeline is the culprit since the legacy PM didn't do inlining at -O1 but the new PM does a little.

There's some discussion around -Og right now.

Some examples on when inlining makes it hard to debug would be good. Also -fno-inline-functions to suppress inlining everywhere.

[jeremy-murphy]

Could you please try 17 Release Candidate or main branch? https://godbolt.org should be helpful.

Same result.

[mr-matthew-jones]

Some examples on when inlining makes it hard to debug would be good.

Inlining can make debugging harder because the control flow of the program potentially skips stack frames and no longer represents the original structure of the code.

For example, in the original godbolt example, the when stepping through say_ im_debugging_this() the function call to goodbye_function() no longer appears. In complex codebases this can make it more difficult to reason about code behaviour and relate debugging observations back to the source code.

[Trass3r]

Right now -Og is equivalent to -O1.

Apparently there has finally been some movement, at least -Og now implies -O1 -fextend-variable-liveness=all.
Flag was introduced in 20.1.0 and added to -Og in 21.1.0: 36af734

[dwblaikie]

While there's certainly room to make -Og diverge further from -O1 - I'd say (though this is far from authoritative) it'd be worth looking into ways to improve the inlining debug info/debugging experience before resorting to disabling inlining in -Og.

The case where code is fully optimized away, like the original example - might not be much to be done about that without some means of artificial stop points (location/line table "views" I think is something GCC implemented and I forget if it's been accepted into the DWARF standard - might be in DWARFv6 draft? Worth checking) -essentially add artificial stopping points that don't move the program counter forward & can have different values for variables. This'd be generally useful for code like "a = 3; a = 7; a = 2; return a;" where all but the last assignment are thrown away as dead stores.

Other cases unrelated to inlining probably deserve their own bugs & we can look at whether the debugging experience can be improved without substantially harming the optimization level of -Og to keep things debuggable but a bit speedier (at compile time (the benefits of inlining and other optimizations at -O1 include improved compile time by reducing the amount of code that needs to be furtehr optimized or emitted, etc) and runtime) than going all the way back to -O0

[Trass3r]

it'd be worth looking into ways to improve the inlining debug info/debugging experience

Wasn't there some tool by Sony to quantify that, track regressions etc?

the benefits of inlining and other optimizations at -O1 include improved compile time by reducing the amount of code that needs to be furtehr optimized or emitted

In the past I actually had the opposite case with 1 codebase, I guess due to templates. Optimizing them took way too long for development iterations so I had to go back to -O0.

[dwblaikie]

the benefits of inlining and other optimizations at -O1 include improved compile time by reducing the amount of code that needs to be furtehr optimized or emitted

In the past I actually had the opposite case with 1 codebase, I guess due to templates. Optimizing them took way too long for development iterations so I had to go back to -O0.

Yeah, it's not uncommon that some optimizations are generally positive but have some negative situations - test cases/issues filed are certainly appreciated to trying to improve these things.