<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 18, 2016 at 10:11 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Nov 18, 2016, at 9:55 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="gmail_msg" target="_blank">dexonsmith@apple.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> No comment on whether we need an offset/etc.; but assuming we do want that some day, it might be more efficient to add an offset field to DIGlobalVariableExpr:<br class="gmail_msg">
><br class="gmail_msg">
> DIGlobalVariableExpr(value: DW_OP_const 42, offset: 32 bits) -> DIGlobalVariable(name: foo)<br class="gmail_msg">
<br class="gmail_msg">
I'm very much against this. We probably want to share as much infrastructure as possible between global and local variables. Putting special support into DIGlobalVariableExpresssion moves us farther away from that goal.<br class="gmail_msg">
<br class="gmail_msg">
With DIExpression (which is really a DWARF expression) we have an extensible representation for all sorts of operations that may be necessary to reconstruct a source variable. I'm fine with improving the syntax to make it more readable, but I would not want to make it any less generic.<br class="gmail_msg"></blockquote><div><br></div><div>I'm still pretty confused about how any of this works correctly - before even trying to wrap my head around how these things would be generic for pieces of a variable. (we don't use the local variable descriptions this way - each description is a complete description of the variable (as complete as we know), possibly overlapping in time/instruction region (do we support that? probably not right now?))<br><br>Not sure what generality you're considering drawing from this or how it might look. I think the same concerns (how do we manipulate expressions when optimizing, etc) I was describing apply for local variables too, so I wouldn't see it as less general.<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
-- adrian<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On 2016-Nov-18, at 09:51, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> 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:<br class="gmail_msg">
>><br class="gmail_msg">
>> DIGlobalVariableExpr(value: DW_OP_const 42) -> DIGlobalVariableFragment(offset: 32 bits) -> DIGlobalVariable(name: foo)<br class="gmail_msg">
>><br class="gmail_msg">
>> (just guessing/pretending there's a DW_OP_const for constant values - I forget how it all works, but purely for demonstration purposes)<br class="gmail_msg">
>><br class="gmail_msg">
>> 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))<br class="gmail_msg">
>><br class="gmail_msg">
>> Perhaps keeping the bit_piece parts out of the DWARF expression bytes and in a separate field of the DIGlobalVariableExpr?<br class="gmail_msg">
>><br class="gmail_msg">
>> DIGlobalVariableExpr(offset: 32, value: DW_OP_const 42)<br class="gmail_msg">
>><br class="gmail_msg">
>> 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?<br class="gmail_msg">
>><br class="gmail_msg">
>> Maybe this doesn't matter - Ih aven't looked at much of the expression/location handling code.<br class="gmail_msg">
>><br class="gmail_msg">
>> On Fri, Nov 18, 2016 at 9:32 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="gmail_msg" target="_blank">aprantl@apple.com</a>> wrote:<br class="gmail_msg">
>> aprantl removed rL LLVM as the repository for this revision.<br class="gmail_msg">
>> aprantl updated this revision to Diff 78544.<br class="gmail_msg">
>> aprantl added a comment.<br class="gmail_msg">
>><br class="gmail_msg">
>> Improved type-safety by adding a DIGlobalVarExpr pointer union.<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> <a href="https://reviews.llvm.org/D26769" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D26769</a><br class="gmail_msg">
>><br class="gmail_msg">
>> Files:<br class="gmail_msg">
>>  include/llvm/Bitcode/LLVMBitCodes.h<br class="gmail_msg">
>>  include/llvm/IR/DIBuilder.h<br class="gmail_msg">
>>  include/llvm/IR/DebugInfo.h<br class="gmail_msg">
>>  include/llvm/IR/DebugInfoMetadata.h<br class="gmail_msg">
>>  include/llvm/IR/GlobalVariable.h<br class="gmail_msg">
>>  include/llvm/IR/Metadata.def<br class="gmail_msg">
>>  lib/Analysis/ModuleDebugInfoPrinter.cpp<br class="gmail_msg">
>>  lib/AsmParser/LLParser.cpp<br class="gmail_msg">
>>  lib/Bitcode/Reader/BitcodeReader.cpp<br class="gmail_msg">
>>  lib/Bitcode/Writer/BitcodeWriter.cpp<br class="gmail_msg">
>>  lib/CodeGen/AsmPrinter/CodeViewDebug.cpp<br class="gmail_msg">
>>  lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp<br class="gmail_msg">
>>  lib/CodeGen/AsmPrinter/DwarfCompileUnit.h<br class="gmail_msg">
>>  lib/CodeGen/AsmPrinter/DwarfDebug.cpp<br class="gmail_msg">
>>  lib/IR/AsmWriter.cpp<br class="gmail_msg">
>>  lib/IR/DIBuilder.cpp<br class="gmail_msg">
>>  lib/IR/DebugInfo.cpp<br class="gmail_msg">
>>  lib/IR/DebugInfoMetadata.cpp<br class="gmail_msg">
>>  lib/IR/LLVMContextImpl.h<br class="gmail_msg">
>>  lib/IR/Metadata.cpp<br class="gmail_msg">
>>  lib/IR/Verifier.cpp<br class="gmail_msg">
>>  lib/Transforms/IPO/StripSymbols.cpp<br class="gmail_msg">
>>  lib/Transforms/Instrumentation/AddressSanitizer.cpp<br class="gmail_msg">
>>  test/Assembler/diglobalvariable.ll<br class="gmail_msg">
>>  test/Assembler/diglobalvariableexpression.ll<br class="gmail_msg">
>>  test/Bitcode/DIGlobalVariableExpr.ll<br class="gmail_msg">
>>  test/Bitcode/DIGlobalVariableExpr.ll.bc<br class="gmail_msg">
>>  test/Bitcode/diglobalvariable-3.8.ll<br class="gmail_msg">
>>  test/Bitcode/diglobalvariable-3.8.ll.bc<br class="gmail_msg">
>>  test/DebugInfo/X86/multiple-at-const-val.ll<br class="gmail_msg">
>>  test/DebugInfo/X86/pr12831.ll<br class="gmail_msg">
>>  test/DebugInfo/X86/split-global.ll<br class="gmail_msg">
>>  test/DebugInfo/X86/stack-value-dwarf4.ll<br class="gmail_msg">
>>  test/DebugInfo/X86/unattached-global.ll<br class="gmail_msg">
>>  test/Transforms/GlobalMerge/debug-info.ll<br class="gmail_msg">
>>  unittests/IR/MetadataTest.cpp<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>