[PATCH] D26769: [IR] Remove the DIExpression field from DIGlobalVariable.
Adrian Prantl via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 18 10:00:43 PST 2016
> On Nov 18, 2016, at 9:51 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> Would it be reasonable/useful to add another level of indirection while we're here - that would describe which part of the variable is being described by this location:
>
> DIGlobalVariableExpr(value: DW_OP_const 42) -> DIGlobalVariableFragment(offset: 32 bits) -> DIGlobalVariable(name: foo)
>
> (just guessing/pretending there's a DW_OP_const for constant values - I forget how it all works, but purely for demonstration purposes)
>
> That way code manipulating DIGlobalVariableExprs wouldn't need to have explicit knowledge of which part of the variable is being described here. (I suppose that could end up with us creating a bottom-up expression tree in metadata, which probably isn't ideal (too heavyweight))
The nice thing about the Dwarf expressions being a stack-based post-fix-notated programming language is that it you can compose functions by simply concatenating them. The typical kind of manipulations that we do (for example, adding an "add offset", "dereference" operation) can done by simply putting the new expression in front of the old expression. I don't think it can get much simpler than that :-)
--- adrian
>
> Perhaps keeping the bit_piece parts out of the DWARF expression bytes and in a separate field of the DIGlobalVariableExpr?
>
> DIGlobalVariableExpr(offset: 32, value: DW_OP_const 42)
>
> Then at least when a variable moves around (does that happen? maybe? - I suppose something like asan, smooshing everything into a single alloca would move something around without splitting it up) the expression can be updated relatively simply without unpacking through a DW_OP_bit_piece, etc?
>
> Maybe this doesn't matter - Ih aven't looked at much of the expression/location handling code.
>
> On Fri, Nov 18, 2016 at 9:32 AM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> aprantl removed rL LLVM as the repository for this revision.
> aprantl updated this revision to Diff 78544.
> aprantl added a comment.
>
> Improved type-safety by adding a DIGlobalVarExpr pointer union.
>
>
> https://reviews.llvm.org/D26769 <https://reviews.llvm.org/D26769>
>
> Files:
> include/llvm/Bitcode/LLVMBitCodes.h
> include/llvm/IR/DIBuilder.h
> include/llvm/IR/DebugInfo.h
> include/llvm/IR/DebugInfoMetadata.h
> include/llvm/IR/GlobalVariable.h
> include/llvm/IR/Metadata.def
> lib/Analysis/ModuleDebugInfoPrinter.cpp
> lib/AsmParser/LLParser.cpp
> lib/Bitcode/Reader/BitcodeReader.cpp
> lib/Bitcode/Writer/BitcodeWriter.cpp
> lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
> lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
> lib/CodeGen/AsmPrinter/DwarfCompileUnit.h
> lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> lib/IR/AsmWriter.cpp
> lib/IR/DIBuilder.cpp
> lib/IR/DebugInfo.cpp
> lib/IR/DebugInfoMetadata.cpp
> lib/IR/LLVMContextImpl.h
> lib/IR/Metadata.cpp
> lib/IR/Verifier.cpp
> lib/Transforms/IPO/StripSymbols.cpp
> lib/Transforms/Instrumentation/AddressSanitizer.cpp
> test/Assembler/diglobalvariable.ll
> test/Assembler/diglobalvariableexpression.ll
> test/Bitcode/DIGlobalVariableExpr.ll
> test/Bitcode/DIGlobalVariableExpr.ll.bc
> test/Bitcode/diglobalvariable-3.8.ll
> test/Bitcode/diglobalvariable-3.8.ll.bc
> test/DebugInfo/X86/multiple-at-const-val.ll
> test/DebugInfo/X86/pr12831.ll
> test/DebugInfo/X86/split-global.ll
> test/DebugInfo/X86/stack-value-dwarf4.ll
> test/DebugInfo/X86/unattached-global.ll
> test/Transforms/GlobalMerge/debug-info.ll
> unittests/IR/MetadataTest.cpp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161118/9394d463/attachment.html>
More information about the llvm-commits
mailing list