https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #23 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- > 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? code insns and markers are potential inspection points, so binds reaching them should ideally not be messed with. this means one can safely remove binds that are overridden before the next inspection point, so yes, keeping only the last one that provides a binding for any given variable before each inspection point should be safe. this should (in theory) be reasonably rare, though, because there should be sequence points between assignments to the same variable. this doesn't imply inspection points, e.g., we don't insert markers at comma operators. I suppose these arise from binds inserted by CFG rearrangements rather than when entering SSA. I don't have much of a sense of these yet, but it's clear their meaning is looser, in a way. They don't refer to a specific code location or bind present in sources, but rather they indicate our inability to keep track of bindings after certain transformations. My intuition is that, as things are, we could drop them in the same circumstances we'd drop overriding binds, but maybe we could go looser about them, especially when they're resets. 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. > # DEBUG INLINE_ENTRY NULL That is a marker, but without naming the inlined function, it would appear to be useless indeed. I wonder, however, if the logical block that named the inlined function was really lost, or if it just references some anonymous function. This would guide the decision on whether the marker became useless for losing track of the function named by it (which might require an investigation of how this came about, instead of silently dropping further debug info), or whether we just don't have a name for the function any more (but we might still have debug info generated for it) > 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.
