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

Francois Pichet via llvm-dev llvm-dev at lists.llvm.org
Wed May 11 13:37:27 PDT 2016


Yes I looked at LiveDebugValues and it is an improvement. But in some cases
it doesn't give me a debug value for variables that are obviously in a
register.

Good debug experience for optimized code is critical for my (out-of-tree)
target.

So I was looking at improving LiveDebugValues and I realized
that unilaterally extending DEBUG_VALUE in ssa form was simpler and it gave
me good results. I know I am lacking specifics here but I just wonder if
its a good approach.


On Wed, May 11, 2016 at 4:16 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.
>
>
> This thread is almost a year old now :-)
> Have you looked at the LiveDebugValues pass that resulted from this
> conversation since?
>
> -- adrian
>
>
>
> On Wed, Aug 12, 2015 at 11:11 AM, Vikram TV via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> An early implementation of extending debug ranges and providing multiple
>> location support is done here: http://reviews.llvm.org/D11933
>>
>> Design document:
>> https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/dd5d9823/attachment.html>


More information about the llvm-dev mailing list