[PATCH] D26769: [IR] Remove the DIExpression field from DIGlobalVariable.

[David Blaikie via llvm-commits]

On Fri, Nov 18, 2016 at 10:00 AM Adrian Prantl <aprantl at apple.com> wrote:

> 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 :-)
>

Wouldn't the piece/bit_piece need to go on top level of the expression
tree? I don't think you can simply concatenate things on top of it...

Oh, also, DW_OP_bit_piece is ordered, judging by the examples in the spec:

DW_OP_reg3 DW_OP_piece 4 DW_OP_reg10 DW_OP_piece 2
 A variable whose first four bytes reside in register 3 and whose next two
bytes reside in register 10.

So how do we know which DIGlobalVariableExpr goes first? Or if there are
holes between exprs?

(am I making sense? not sure - I can try to explain differently, or perhaps
just not understanding)


>
> --- 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> 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
>
> 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/b0c94f78/attachment.html>