This patch stems from D84112. This patch includes improvement in debuginfo salvaging.
Details
Diff Detail
Event Timeline
Could you elaborate on why module-level information needs to be preserved? As mentioned on llvm-dev, I think you might have missed a place where promotion from stack to SSA/values happens -- IMHO we shouldn't add module-level debuginfo-tracking unless it's absolutely necessary.
| llvm/include/llvm/IR/Module.h | ||
|---|---|---|
| 205 | You'll need to use a value handle (WeakVH perhaps) to store Value references, to avoid storing pointers that become dangling pointers later. The comment should indicate what's being mapped -- I believe it's old alloca to the DILocalVariable, because insertVarAddressMap inserts the second operand of a dbg.declare? In addition, it looks like salvageDebugInfoForDbgValues never dereferences the mapped value, so could this instead be a set instead of a map? | |
| llvm/lib/IR/Instruction.cpp | ||
| 81–82 | Does this make the debug-info metadata code in the Instruction destructor redundant? | |
| 800–803 | The rest of Instruction.cpp is very detail-agnostic, and it seems out of place to check the DWARF version here (and presumably meaningless for CodeView). Could this be turned into a more generic compile option, or target option, so that it's less DWARF specific? (It might be that LLVM doesn't support such a form of option). | |
| 812–813 | Quite a lot of this function is now dedicated to "if we're an alloca being deleted, that had associated dbg.declares". IMO, it's clearer to put that code into a separate function. | |
| llvm/test/DebugInfo/X86/implicit_pointer_temp_dyn_alloc.cc | ||
| 2–3 | We can't call clang from within llvm as it's not guaranteed to be built. Getting the unoptimised IR with -O0 -gdwarf-5 -emit-llvm -S -Xclang -disable-O0-optnone, and writing a normal lit test for that, would be best. You might also want to put an end-to-end Dexter test into the debuginfo-tests. | |
| llvm/unittests/IR/DebugInfoTest.cpp | ||
| 186 | This should be a positive test that the dbg.value points at a correct thing, not that it doesn't point at an undef. There are a variety of other Values it could point at by mistake. | |
| llvm/include/llvm/Transforms/Utils/Local.h | ||
|---|---|---|
| 312 | Can we leave this here in Local ? | |
| llvm/lib/IR/Instruction.cpp | ||
| 797 | nit: Preserve | |
| 822 | why only for DWARF 5? | |
| 822 | Please add a comment describing what we are doing here. | |
| 825 | Please use early continue here. | |
| llvm/lib/IR/Instruction.cpp | ||
|---|---|---|
| 822 | 'later version' --> I meant earlier | |
You'll need to use a value handle (WeakVH perhaps) to store Value references, to avoid storing pointers that become dangling pointers later. The comment should indicate what's being mapped -- I believe it's old alloca to the DILocalVariable, because insertVarAddressMap inserts the second operand of a dbg.declare?
In addition, it looks like salvageDebugInfoForDbgValues never dereferences the mapped value, so could this instead be a set instead of a map?