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

> 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
<mailto: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 <mailto: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
<mailto:aprantl at apple.com>> wrote:
>> 
>>> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at
gmail.com <mailto: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 <mailto:aprantl at apple.com>> wrote:
>>> 
>>> > On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at
gmail.com <mailto: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/330acf6c/attachment.html>

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>

On Sat, May 14, 2016 at 1:59 AM, Francois Pichet <pichet2000 at gmail.com>
wrote:
> 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.
>
True. And currently, LiveDebugValues cannot propagate <R5, argc> to BB1 as
join fails with one of the predecessor - BB3.

Here is my thought about handling similar cases:
I would regard BB1 to be special because join fails to propagate the debug
value which is dependent on itself through a cycle. Such blocks need to be
identified and handled slightly differently. I think one way to identify
them is by using dominator info - look for blocks that dominate its
predecessors and propagate debug values from other predecessors
unconditionally (also note down the propagated values). This is to be done
early during OutLocs initialization. Further, transfer-join would happen
normally.

If join() fails for these special blocks, the propagated debug values need
to be reverted (followed by another round of convergence for its
successors) and surely this will need extra book-keeping.
>
>
>
>
>
> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

-- 

Good time...
Vikram TV
CompilerTree Technologies
Mysore, Karnataka, INDIA
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/6e27c837/attachment.html>