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