[llvm-dev] [LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator

[Francois Pichet via llvm-dev]

In retrospect I totally agree with you. I am looking at LiveDebugValue
again to see if I can improve certain specific cases.

On Wed, May 11, 2016 at 5:14 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote:
>
> Good point.
>
> Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize
> this might be wrong in some (corner?) cases where vreg0 no longer refer to
> "x"
>
> My fix would be to propagate the DEBUG_VALUE only if "x" is associated
> with only a single virtual register.
> BTW, my goal is to generally improve DEBUG_VALUE for optimized code, not
> make it 100% correct.
>
>
> I hold the (perhaps somewhat extreme) position that having debug info the
> *may* be correct is worse than having no debug info at all, because it
> means that — in the end — you then cannot trust *anything* reported by the
> debugger. (There are some debatable corner cases, for example, in contrast
> to the debugger, the user may know over which path the control flow arrived
> at the current break point, but these are far in between.)
>
> That said, I’m very open to improvements to the quality and correctness,
> so please don’t feel discouraged :-)
>
> -- adrian
>
>
> On Wed, May 11, 2016 at 4:43 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> > On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > Regarding the problem of debug range for optimized code.
>> > Currently a DEBUG_VALUE will be inserted after the <def>vregX
>> > DEBUG_VALUE are only valid until the end of the current
>> MachineBasicBlock. That's the main problem.
>> > Why not simply iterate over all uses of vregX and insert an DEBUG_VALUE
>> in all the MachineBasicBlocks where vregX is used. (pre regalloc)
>> >
>> > I prototyped a small pass to do that and at first it seems to improve
>> .debug_loc range validity and enhance the debugging experience for
>> optimized code.
>>
>> The problem that I see with this approach is that DEBUG_VALUEs are only
>> valid until the next DEBUG_VALUE that describes the same variable. How does
>> your pass handle:
>>
>>   BB0:
>>     DEBUG_VALUE “x”, vreg0
>>
>>   | |
>>   | BB1:
>>   |  DEBUG_VALUE “x”, vreg1
>>   | |
>>   \_____BB2:
>>     |    |
>>     |____/
>>   BB2:
>>     vreg0 // still not clobbered here.
>>
>> Does it insert a DEBUG_VALUE “x”, vreg0 into BB2?
>>
>> -- adrian
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/d0e0d425/attachment.html>