Re: [PR58315] reset inlined debug vars at return-to point

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Feb 26, 2015 at 11:29:35AM +0100, Richard Biener wrote:
> I claim you can achieve the same result by effectively inserting
> those reset debug insns right before var-tracking itself and by
> re-computing BLOCK "liveness".  That will automatically deal
> with code motion that extends the life-range of an inlined BLOCK
> by moving stmts (still associated with that BLOCK) across the
> return point of the inlined call (and thus across your debug resets).
> And it will allow var-tracking to eventually compute locations for
> vars at the "entry" of that BLOCK piece.

If that would work, it would be nice, but I'm not sure how you can do that.
Using something like final.c (reemit_insn_block_notes) you can discover
the ranges of scopes (inline functions and lexical blocks).
If some scope has a single range, it is the easy case, you know where it
starts and where it ends.  For scopes with multiple ranges, how can you find
out what case it is though?  I mean, either it can be just the case that
some instruction(s) with different scope got scheduled (or sunk / whatever)
in between the instructions of the scope, in that case resetting the vars
there is highly undesirable (would majorly grow the .debug_loc lists and
break debuggers, e.g. when you try to watch some variable through the live
of some inline, if you reset it any time a single unrelated insn is
encountered, the debugger would need to tell you the var got lost/changed).
Or it can be the case of unrolled loop which has lexical scopes or inlines
in it, in that case you will have multiple "same" scopes, but in that case
it is unnecessary to preserve variables in between those, it is really
different inlines.

	Jakub