mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 18:54:02 +01:00
574bf7e17c
Summary: 1) Make sure to discard dangling debug info if the variable (or variable fragment) is mapped to something new before we had a chance to resolve the dangling debug info. 2) When resolving debug info, make sure to bump the associated SDNodeOrder to ensure that the DBG_VALUE is emitted after the instruction that defines the value used in the DBG_VALUE. This will avoid a debug-use before def scenario as seen in https://bugs.llvm.org/show_bug.cgi?id=36417. The new test case, test/DebugInfo/X86/sdag-dangling-dbgvalue.ll, show some other limitations in how dangling debug info is handled in the SelectionDAG. Since we currently only support having one dangling dbg.value per Value, we will end up dropping debug info when there are more than one variable that is described by the same "dangling value". Reviewers: aprantl Reviewed By: aprantl Subscribers: aprantl, eraman, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44369 llvm-svn: 327303 |
||
---|---|---|
.. | ||
Analysis | ||
AsmParser | ||
BinaryFormat | ||
Bitcode | ||
CodeGen | ||
DebugInfo | ||
Demangle | ||
ExecutionEngine | ||
Fuzzer | ||
FuzzMutate | ||
IR | ||
IRReader | ||
LineEditor | ||
Linker | ||
LTO | ||
MC | ||
Object | ||
ObjectYAML | ||
Option | ||
Passes | ||
ProfileData | ||
Support | ||
TableGen | ||
Target | ||
Testing | ||
ToolDrivers | ||
Transforms | ||
WindowsManifest | ||
XRay | ||
CMakeLists.txt | ||
LLVMBuild.txt |