On 4 September 2012 21:42, Hans-Peter Nilsson <h...@bitrange.com> wrote: > On Mon, 3 Sep 2012, Richard Guenther wrote: >> On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther <rguent...@suse.de> wrote: >> > >> > This adds a new optimization level, -Og, as previously discussed. >> > It aims at providing fast compilation, a superior debugging >> > experience and reasonable runtime performance. Instead of making >> > -O1 this optimization level this adds a new -Og. >> > >> > It's a first cut, highlighting that our fixed pass pipeline and >> > simply enabling/disabling individual passes (but not pass copies >> > for example) doesn't scale to properly differentiate between >> > -Og and -O[23]. -O1 should get similar treatment, eventually >> > just building on -Og but not focusing on debugging experience. >> > That is, I expect that in the end we will at least have two post-IPA >> > optimization pipelines. It also means that you cannot enable >> > PRE or VRP with -Og at the moment because these passes are not >> > anywhere scheduled (similar to the situation with -O0). >> > >> > It has some funny effect on dump-file naming of the pass copies >> > though, which hints at that the current setup is too static. >> > For that reason the new queue comes after the old, to not confuse >> > too many testcases. >> > >> > It also does not yet disable any of the early optimizations that >> > make debugging harder (SRA comes to my mind here, as does >> > switch-conversion and partial inlining). > > Please, no inlining. Think of stack back-traces and their use > when debugging.
I would argue [without sufficient knowledge of how easy this would actually be to do in a real compiler :-)] that this is a debugger problem and not a compiler issue. With DWARF as the debug info format it should certainly be possible to produce a view that looked like: $ bt #0b baz (...) #0a inlined into bar (...) #0 inlined into foo (...) #1 do_something #2 main This would involve reading the .debug_frame, and then looking up the inlined subroutines via .debug_info. I personally would like as much optimisation as possible at -Og that doesn't break a defined level of debug illusion. I have seen too many cases where people debug at -O0/-O1 and then build a release with a -O2/-O3 build and get bitten by undefined behaviour issues. The more optimised -Og code is the less the reason to release a build at a higher optimisation level. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
