[llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value

[Adrian Prantl via llvm-dev]

> On Sep 6, 2017, at 3:24 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 5 September 2017 at 21:00, Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Debug info today handles two cases reasonably well:
>> 1. At -O0, dbg.declare does a good job describing variables that live at
>> some known stack offset
>> 2. With optimizations, variables promoted to SSA can be described with
>> dbg.value
>> 
>> This leaves behind a large hole in our optimized debug info: variables that
>> cannot be promoted, typically because they are address-taken. This is
>> https://llvm.org/pr34136, and this RFC is mostly about addressing that.
>> 
>> The status today is that instcombine removes all dbg.declares and
>> heuristically inserts dbg.values where it can identify the value of the
>> variable in question. This prevents us from having misleading debug info,
>> but it throws away information about the variable’s location in memory.
> 
> Hi Reid, thanks for writing such a clear summary of the problem that
> this RFC addresses. I was wondering if there is any sort of
> methodology for quantifying the "quality" of debug information? e.g.
> the gap between the current debug information and 'ideal' debug info?

It is difficult. One thing we can do is measure the delta between the debug info quality of two compiler version (https://reviews.llvm.org/D36627 <https://reviews.llvm.org/D36627> adds an option to collect various metrics to that end to llvm-dwarfdump).

-- adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/baaf826d/attachment.html>