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

[Francois Pichet via llvm-dev]

Here is a specific case that make the debugging experiences degraded on my
target:
This is a loop simplified CFG:

BB#0:
  %R5<def> = OR_rr %R0, %R49    // this is %R5 only def.
  DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4
   Successors according to CFG: BB#1

BB#1:
    Live Ins: %R5
    Predecessors according to CFG: BB#0 BB#3
    ...
    Successors according to CFG: BB#2 BB#4

BB#2:
    Live Ins: %R5
    Predecessors according to CFG: BB#1
  ...
    Successors according to CFG: BB#3

BB#3:
    Live Ins: %R5
    Predecessors according to CFG: BB#2
  ...
    Successors according to CFG: BB#1

BB#4:
    Predecessors according to CFG: BB#1


Its obvious to me that the DEBUG_VALUE %R5, %noreg, !"argc" should be
propagated to BB#1, BB#2 and BB#3.

LiveDebugValue will currently not handle this case. The propagation will
not be done for BB#1 because one of its predecessor BB3# doesn't have a
DEBUG_VALUE %R5. But R5 is still guaranteed to correspond to argc.

I am investigating how to extend LiveDebugValue for a case like this.


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

> The most obvious place where it is lacking at the moment is that it only
> supports DBG_VALUEs in registers. Adding support for constant values,
> memory locations, and fp constants would be a big win!
>
> thanks,
> Adrian
>
> On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote:
>
> 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/20160512/2ed0db9d/attachment.html>