Richard Biener <richard.guent...@gmail.com> writes: > On Sun, Jun 23, 2019 at 3:51 PM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> To get an idea of the runtime cost, I tried compiling tree-into-ssa.ii >> at -O2 -g with various --enable-checking=yes builds of cc1plus: >> >> time taken >> cc1plus compiled with -O0: 100.00% (baseline) >> cc1plus compiled with old -Og: 30.94% > > is this -Og -g or just -Og? I suppose all numbers are with -g enabled?
Yeah, all with -g enabled. But these were the options used to build cc1plus, whereas the timings are for running it. So -g shouldn't make a difference. >> cc1plus compiled with new -Og: 31.82% >> cc1plus compiled with -O1g: 28.22% >> cc1plus compiled with -O1: 26.72% >> cc1plus compiled with -O2: 25.15% >> >> So there is a noticeable but small performance cost to the new mode. >> >> To get an idea of the compile-time impact, I tried compiling >> tree-into-ssa.ii at various optimisation levels, all using the >> same --enable-checking=release bootstrap build: >> >> time taken >> tree-into-ssa.ii with -O0 -g: 100.0% (baseline) >> tree-into-ssa.ii with old -Og -g: 180.6% >> tree-into-ssa.ii with new -Og -g: 198.2% >> tree-into-ssa.ii with -O1g -g: 237.1% >> tree-into-ssa.ii with -O1 -g: 211.8% >> tree-into-ssa.ii with -O2 -g: 331.5% >> >> So there's definitely a bit of a compile-time hit. I haven't yet looked >> at how easy it would be to fix. >> >> What do you think? Is it worth pursuing this further? >> >> Of course, even if we do do this, it's still important that the debug >> info for things like -O2 -g is as good as it can be. I just think some >> of the open bugs against -Og fundamentally can't be fixed properly while >> -Og remains a cut-down version of -O1. > > Thanks for doing this experiment. I'm not sure extra complication > is welcome (but didn't look into the patch(es) yet...). OK. The complication is in having (to think about) a new pair of conditions that might be relevant: tangible/shadow instead of nondebug/debug. But almost all the changes involve replacing the latter with the former rather than adding new checks. Hopefully once the whole sourcebase has been converted, the check would become second nature. (But patch 1 doesn't convert the whole sourcebase.) > My original motivation for -Og -g was to provide -O0 -g compile-time > at -O1 runtime with better debuggability than -O0 -g (mainly because > that doesn't enable var-tracking). Of course that failed completely ;) We fall short on the compile-time side, but being able to get a reasonable debugging experience with code that runs 3 times faster than -O0 is still a pretty nice feature. :-) > I somewhat like the idea that -ONg forces debug info generation > (but not necessarily output without -g) and thus we can take debug-stmts > into account. I suppose you're simply keying on optimize_debug here. I wondered about doing it that way, but in the end added a new internal variable instead (flag_tangible_debug, but not backed by a real -f option). optimize_debug mostly disables optimisations, and whether we want to do that for -ONg felt like a separate question from whether we should take debug stmts into account. Thanks, Richard
