Re: [PATCH 0/3] RFC: Let debug stmts influence codegen at -Og

[Richard Biener <richard dot guenther at gmail dot com>]

On Sun, Jun 23, 2019 at 3:51 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> -Og is documented as:
>
>   @option{-Og} should be the optimization
>   level of choice for the standard edit-compile-debug cycle, offering
>   a reasonable level of optimization while maintaining fast compilation
>   and a good debugging experience.  It is a better choice than @option{-O0}
>   for producing debuggable code because some compiler passes
>   that collect debug information are disabled at @option{-O0}.
>
> One of the things hampering that is that, as for the "normal" -O* flags,
> the code produced by -Og -g must be the same as the code produced
> without any debug IL at all.  There are many cases in which that makes
> it impossible to stop useful values from being optimised out of the
> debug info, either because the value simply isn't available at runtime
> at the point that the debugger needs it, or because of limitations in
> the debug representation.  (E.g. pointers to external data are dropped
> from debug info because the relocations wouldn't be honoured.)
>
> I think it would be better to flip things around so that the debug IL
> is always present when optimising at -Og, and then allow the debug IL
> to influence codegen at -Og.  This still honours the -fcompare-debug
> principle, and the compile speed of -Og without -g doesn't seem very
> important.

Just to note it's also a common user misconception that -Og enables
debug-info ...

> This series therefore adds a mode in which debug stmts and debug insns
> are present even without -g and are explicitly allowed to affect codegen.
> In particular, when this mode is active:
>
> - uses in debug binds become first-class uses, acting like uses in
>   executable code
>
> - the use of DEBUG_EXPR_DECLs is banned.  If we want to refer to
>   a temporary value in debug binds, we need to calculate the value
>   with executable code instead
>
> This needs a new term to distinguish stmts/insns that affect codegen
> from those that don't.  I couldn't think of one that I was really
> happy with, but possibilities included:
>
>     tangible/shadow
>     manifest/hidden
>     foreground/background
>     reactive/inert
>     active/dormant   (but "active insn" already means something else)
>     peppy/sullen
>
> The series uses tangible/shadow.  There's a new global flag_tangible_debug
> that controls whether debug insns are "tangible" insns (for the new mode)
> or "shadow" insns (for normal optimisation).  -Og enables the new mode
> while the other optimisation levels leave it off.  (Despite the name,
> the new variable is just an internal flag, there's no -ftangible-debug
> option.)
>
> The first patch adds the infrastructure but doesn't improve the debug
> experience much on its own.
>
> As an example of one thing we can do with the new mode, the second patch
> ensures that the gimple IL has debug info for each is_gimple_reg variable
> throughout the variable's lifetime.  This fixes a couple of the PRs in
> the -Og meta-bug and from spot-testing seems to ensure that far fewer
> values are optimised out.
>
> Also, the new mode is mostly orthogonal to the optimisation level
> (although it would in effect disable optimisations like loop
> vectorisation, until we have a way of representing debug info for
> vectorised loops).  The third patch therefore adds an -O1g option
> that optimises more heavily than -Og but provides a better debug
> experience than -O1.
>
> I think -O2g would make sense too, and would be a viable option
> for people who want to deploy relatively heavily optimised binaries
> without compromising the debug experience too much.
>
> Other possible follow-ons for the new mode include:
>
> - Make sure that tangible debug stmts never read memory or take
>   an address.  (This is so that addressability and vops depend
>   only on non-debug insns.)
>
> - Fall back on expanding real code if expand_debug_expr fails.
>
> - Force debug insns to be simple enough for dwarf2out (e.g. no external
>   or TLS symbols).  This could be done by having a validation step for
>   debug insns, like we already do for normal insns.
>
> - Prevent the removal of dead stores if it would lead to wrong debug info.
>   (Maybe under control of an option?)
>
> 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?

> 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...).

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 ;)

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.

Richard.

> Thanks,
> Richard