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

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

On Thu, Feb 26, 2015 at 11:42 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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.

I don't claim you can get the "maximal" pruning of the var-tracking
solutions.  I just claim that you can do something sensible by computing
where BLOCKs go dead.  And that this would be better than simply
ignoring the code motion issue alltogether.  If Alexs solution would be
acceptable in terms of that issue then we can as well just insert
debug resets for each variable at initial BLOCK boundaries.  After all
if the inliner inserts resets just for vars that already have debug stmts
then I cook up a testcase where those debug stmts only appear
after inlining.

Indeed if we want to be as close to the source as possible we should
insert debug stmts from the start (where the values are still computed)
so that code-motion will simply make it unavailable (and also reset
locations so you don't get gdb jumping around).

Richard.

>
>         Jakub