https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #23)
> > what are the rules of which ones we can remove? Can we always just keep the
> last? What about location differences? What about possibly interleaving
> DEBUG_BEGIN stmts?
I think Richard's patch only considers debug bind stmts next to each other, any
other stmt like DEBUG BEGIN_STMT, etc. reset the table (i.e. stop the
elimination).
> When you ask about location differences, it's not clear whether you're
> asking about binding values (used in location lists) or source line
> locations. It's not always viable to tell whether binding expressions are
> equivalent, but the last one prevails except at control flow confluences,
> and var-tracking deals with that much later. As for source line locations,
> I don't think they're relevant in debug bind statements.
My understanding is that we completely ignore gimple_location from debug bind
stmts. While debug stmts and later DEBUG_INSNs do have location, the
-fcompare-debug rules should make sure that other stmts/insns location is not
affected by the locations of the debug stmts/insns. And, var-tracking replaces
the DEBUG_INSNs with NOTE_INSN_VAR_LOCATION notes that do not have a locus.
> > my guess that debug temps are always in the same BB as uses is wrong.
>
> they can be bound in one BB and used in another, indeed. they may even be
> bound in multiple BBs and used in multiple other BBs, and then var-tracking
> will attempt to identify shared values in incoming exprs at confluence
> points. we don't do that very much, but we could. even without that, there
> are cases in which we issue temp binds in one block and reference them in
> another, even when we're not sure one reaches the other: var-tracking sorts
> that out eventually.
Besides Richard's eliminate_unnecessary_stmts patch, which you've acked and I'm
going to install soon, there are other patches (GCC 10 only presumably): #c11
and #c16, what do you think about those? The former canonicalizes {CLOBBER}
values of debug stmts to NULL, the latter tries to remove debug stmts for
variables which are not referenced in the function at all and have only NULL
debug binds for them; I believe in such cases the debug insns don't provide
anything over the optimized away vars in the body.
Another thing is if we could also remove DEBUG_EXPR_DECLs by doing analysis
similar to #c16, look through all debug bind stmts, see what DEBUG_EXPR_DECLs
they are refering to, and if there are DEBUG_EXPR_DECLs which are not
referenced in any of them and they aren't referenced in decl_debug_args_lookup
either, just
remove debug bind stmts for those DEBUG_EXPR_DECLs. Similarly, would it be
useful to reset debug bind stmts if they refer to DEBUG_EXPR_DECLs that are
never set (or do it only for some simple cases where we couldn't figure out any
location from the expr)?
