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

[Francois Pichet via llvm-dev]

No, R5 is not clobbered or having a conflicting DBG_VALUE

That sounds more like a missing feature in LiveDebugValue: There is no
DBG_VALUE for R5 in BB#3.
LiveDebugValue will only join when all predecessors have the same DBG_VALUE.




On Thu, May 12, 2016 at 5:04 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com>
> wrote:
>
> 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.
>
>
> That sounds like a bug in LiveDebugValues, or there must be something
> missing from your example. LiveDebugValues should propagate the DBG_VALUE
> in this case. Are you sure that R5 isn’t clobbered or regmask’ed by any
> instruction, and that there is no conflicting DBG_VALUE?
>
> -- adrian
>
>
>
> 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/20160513/702137a9/attachment-0001.html>