[Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer.

[alok]

Summary

This patch stems from D84112.
New dwarf operator DW_OP_LLVM_explicit_pointer is introduced (present only in LLVM IR)

DWARF operator DW_OP_implicit_pointer has some limitations like it should appear only in
beginning and there should be only one operator in expression. This is good for ultimate
dump of dwarf in object file. In case of IR we need more freedom to get rid of limitations, to
cater this the new LLVM-IR level operator DW_OP_LLVM_explicit_pointer is introduced, which
can appear at multiple times to support multilevel-indirection (when intermediate level
variables are not user-defined). This IR level operator is finally translated to DWARF operator
DW_OP_implicit_pointer using artificial variables.

[jmorse]

Similar story to the parent patch, could you put a file-comment into the test explaining it's a round-trip test?

[alok]

Incorporated comments from @jmorse .

[alok]

In D84114#2184522, @jmorse wrote:

Similar story to the parent patch, could you put a file-comment into the test explaining it's a round-trip test?

Thanks for your comment. Just incorporated your comments.

[alok]

@jmorse do you have any more comment on this ?

[dblaikie]

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

[alok]

In D84114#2291599, @dblaikie wrote:

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Thanks for your comment. I shall update the patch description and IR documentation as well.

[alok]

In D84114#2324425, @alok wrote:

In D84114#2291599, @dblaikie wrote:

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Thanks for your comment. I shall update the patch description and IR documentation as well.

The patch description is updated.

[dblaikie]

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

[alok]

In D84114#2336165, @dblaikie wrote:

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).
While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.
though I am open to use any other name.

[dblaikie]

In D84114#2343689, @alok wrote:

In D84114#2336165, @dblaikie wrote:

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).

OK, I'm with you so far, that sounds reasonable to me.

While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.

Sorry, I don't think I'm understanding "This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable"

Oh, this is for a case where, say, I wrote code like this:

const int *f1() {
  static const int x = 3;
  return x;
}
void f2() {
  const int *y = f1();
  ...
}

Why does that need a different DW_OP compared to DW_OP_LLVM_implicit_pointer? Presumably we use dbg.values for variables with constant values without needing extra operators? (so a variable with the constant value 3 is call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression()) and a variable that /points to/ the constant value 3 would, I would've thought, be call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression(DW_OP_LLVM_implicit_pointer))

though I am open to use any other name.

[alok]

In D84114#2355465, @dblaikie wrote:

In D84114#2343689, @alok wrote:

In D84114#2336165, @dblaikie wrote:

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).

OK, I'm with you so far, that sounds reasonable to me.

While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.

Sorry, I don't think I'm understanding "This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable"

Oh, this is for a case where, say, I wrote code like this:

const int *f1() {
  static const int x = 3;
  return x;
}
void f2() {
  const int *y = f1();
  ...
}

Why does that need a different DW_OP compared to DW_OP_LLVM_implicit_pointer? Presumably we use dbg.values for variables with constant values without needing extra operators? (so a variable with the constant value 3 is call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression()) and a variable that /points to/ the constant value 3 would, I would've thought, be call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression(DW_OP_LLVM_implicit_pointer))

though I am open to use any other name.

Thanks for this. It makes sense. I shall keep the same name for initial two usage. For this I shall abort the current patch (D84114) and make the necessary changes in first one D84113 .

llvm/docs/LangRef.rst

- ``DW_OP_breg`` (or ``DW_OP_bregx``) represents a content on the provided
   expression over two registers.
 - ``DW_OP_push_object_address`` pushes the address of the object which can then
   serve as a descriptor in subsequent calculation. This opcode can be used to
   calculate bounds of fortran allocatable array which has array descriptors.
 - ``DW_OP_LLVM_implicit_pointer, N`` can only appear at the
   beginning of a ``DIExpression``, and it specifies the value of variable
   represented by the ``DILocalVariable`` referred to by the instructions 
   value/address operand at offset N.
+- ``DW_OP_LLVM_explicit_pointer`` it specifies the dereferenced value.
 
 DWARF specifies three kinds of simple location descriptions: Register, memory,
 and implicit location descriptions.  Note that a location description is
 defined over certain ranges of a program, i.e the location of a variable may
 change over the course of the program. Register and memory location
 descriptions describe the *concrete location* of a source variable (in the
 sense that a debugger might modify its value), whereas *implicit locations*
 describe merely the actual *value* of a source variable which might not exist

llvm/include/llvm/BinaryFormat/Dwarf.h

 #include "llvm/BinaryFormat/Dwarf.def"
   DW_OP_lo_user = 0xe0,
   DW_OP_hi_user = 0xff,
   DW_OP_LLVM_fragment = 0x1000,         ///< Only used in LLVM metadata.
   DW_OP_LLVM_convert = 0x1001,          ///< Only used in LLVM metadata.
   DW_OP_LLVM_tag_offset = 0x1002,       ///< Only used in LLVM metadata.
   DW_OP_LLVM_entry_value = 0x1003,      ///< Only used in LLVM metadata.
   DW_OP_LLVM_implicit_pointer = 0x100c, ///< Only used in LLVM metadata.
+  DW_OP_LLVM_explicit_pointer = 0x100d, ///< Only used in LLVM metadata.
 };
 
 enum TypeKind : uint8_t {
 #define HANDLE_DW_ATE(ID, NAME, VERSION, VENDOR) DW_ATE_##NAME = ID,
 #include "llvm/BinaryFormat/Dwarf.def"
   DW_ATE_lo_user = 0x80,
   DW_ATE_hi_user = 0xff
 };

llvm/lib/BinaryFormat/Dwarf.cpp

#include "llvm/BinaryFormat/Dwarf.def"
   case DW_OP_LLVM_fragment:
     return "DW_OP_LLVM_fragment";
   case DW_OP_LLVM_tag_offset:
     return "DW_OP_LLVM_tag_offset";
   case DW_OP_LLVM_entry_value:
     return "DW_OP_LLVM_entry_value";
   case DW_OP_LLVM_implicit_pointer:
     return "DW_OP_LLVM_implicit_pointer";
+  case DW_OP_LLVM_explicit_pointer:
+    return "DW_OP_LLVM_explicit_pointer";
   }
 }
 
 unsigned llvm::dwarf::getOperationEncoding(StringRef OperationEncodingString) {
   return StringSwitch<unsigned>(OperationEncodingString)
 #define HANDLE_DW_OP(ID, NAME, VERSION, VENDOR)                                \
   .Case("DW_OP_" #NAME, DW_OP_##NAME)
 #include "llvm/BinaryFormat/Dwarf.def"
       .Case("DW_OP_LLVM_convert", DW_OP_LLVM_convert)
       .Case("DW_OP_LLVM_fragment", DW_OP_LLVM_fragment)
       .Case("DW_OP_LLVM_tag_offset", DW_OP_LLVM_tag_offset)
       .Case("DW_OP_LLVM_entry_value", DW_OP_LLVM_entry_value)
       .Case("DW_OP_LLVM_implicit_pointer", DW_OP_LLVM_implicit_pointer)
+      .Case("DW_OP_LLVM_explicit_pointer", DW_OP_LLVM_explicit_pointer)
       .Default(0);
 }
 
 unsigned llvm::dwarf::OperationVersion(dwarf::LocationAtom Op) {
   switch (Op) {
   default:
     return 0;
 #define HANDLE_DW_OP(ID, NAME, VERSION, VENDOR)                                \

llvm/lib/IR/DebugInfoMetadata.cpp

case dwarf::DW_OP_LLVM_entry_value: {
       return I->get() == expr_op_begin()->get() && I->getArg(0) == 1 &&
              getNumElements() == 2;
     }
     case dwarf::DW_OP_LLVM_implicit_pointer: {
       // A DW_OP_LLVM_implicit_pointer operator must appear at the beginning
       // and it has one argument.
       return (I == expr_op_begin()) && (getNumElements() == 2);
     }
+    case dwarf::DW_OP_LLVM_explicit_pointer:
     case dwarf::DW_OP_LLVM_convert:
     case dwarf::DW_OP_LLVM_tag_offset:
     case dwarf::DW_OP_constu:
     case dwarf::DW_OP_plus_uconst:
     case dwarf::DW_OP_plus:
     case dwarf::DW_OP_minus:
     case dwarf::DW_OP_mul:
     case dwarf::DW_OP_div:

llvm/test/DebugInfo/X86/LLVM_explicit_pointer.ll

+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+
+; CHECK: !DIExpression(DW_OP_LLVM_explicit_pointer)
+
+;---------------------------
+;static const char *b = "opq";
+;volatile int v;
+;int main() {
+;  int var1 = 4;
+;  int *ptr1;
+;
+;  v++;
+;  ptr1 = &var1;
+;  v++;
+;
+;  return *ptr1 - 5;
+;}
+;---------------------------
+
+; ModuleID = 'LLVM_explicit_pointer.c'
+source_filename = "LLVM_explicit_pointer.c"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+@v = common dso_local global i32 0, align 4, !dbg !0
+; Function Attrs: nofree norecurse nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr !dbg !12 {
+entry:
+  call void @llvm.dbg.value(metadata i32 4, metadata !16, metadata !DIExpression()), !dbg !19
+  %0 = load volatile i32, i32* @v, align 4, !dbg !20, !tbaa !21
+  %inc = add nsw i32 %0, 1, !dbg !20
+  store volatile i32 %inc, i32* @v, align 4, !dbg !20, !tbaa !21
+
+  call void @llvm.dbg.value(metadata i32 4, metadata !17, metadata !DIExpression(DW_OP_LLVM_explicit_pointer)), !dbg !19
+
+  %1 = load volatile i32, i32* @v, align 4, !dbg !25, !tbaa !21
+  %inc1 = add nsw i32 %1, 1, !dbg !25
+  store volatile i32 %inc1, i32* @v, align 4, !dbg !25, !tbaa !21
+  ret i32 -1, !dbg !26
+}
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata)
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!8, !9, !10}
+!llvm.ident = !{!11}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "v", scope: !2, file: !3, line: 2, type: !6, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 10.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "LLVM_explicit_pointer.c", directory: "/dir", checksumkind: CSK_MD5, checksum: "218aaa8dc9f04b056b56d944d06383dd")
+!4 = !{}
+!5 = !{!0}
+!6 = !DIDerivedType(tag: DW_TAG_volatile_type, baseType: !7)
+!7 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!8 = !{i32 7, !"Dwarf Version", i32 5}
+!9 = !{i32 2, !"Debug Info Version", i32 3}
+!10 = !{i32 1, !"wchar_size", i32 4}
+!11 = !{!"clang version 10.0.0"}
+!12 = distinct !DISubprogram(name: "main", scope: !3, file: !3, line: 3, type: !13, scopeLine: 3, flags: DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !15)
+!13 = !DISubroutineType(types: !14)
+!14 = !{!7}
+!15 = !{!16, !17}
+!16 = !DILocalVariable(name: "var1", scope: !12, file: !3, line: 4, type: !7)
+!17 = !DILocalVariable(name: "ptr1", scope: !12, file: !3, line: 5, type: !18)
+!18 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64)
+!19 = !DILocation(line: 0, scope: !12)
+!20 = !DILocation(line: 7, column: 4, scope: !12)
+!21 = !{!22, !22, i64 0}
+!22 = !{!"int", !23, i64 0}
+!23 = !{!"omnipotent char", !24, i64 0}
+!24 = !{!"Simple C/C++ TBAA"}
+!25 = !DILocation(line: 9, column: 4, scope: !12)
+!26 = !DILocation(line: 11, column: 3, scope: !12)