[Mlir-commits] [mlir] [mlir] Add support for DIGlobalVariable and DIGlobalVariableExpression (PR #73367)

Tobias Gysi llvmlistbot at llvm.org
Sat Nov 25 08:35:42 PST 2023


================
@@ -109,3 +119,251 @@ bool MemoryEffectsAttr::isReadWrite() {
     return false;
   return true;
 }
+
+//===----------------------------------------------------------------------===//
+// DIExpression
+//===----------------------------------------------------------------------===//
+
+DIExpressionAttr DIExpressionAttr::get(MLIRContext *context) {
+  return get(context, ArrayRef<uint64_t>({}));
+}
+
+#define _FORMAT_DW_OP(x) #x
+#define FORMAT_DW_OP(NAME, VENDOR) _FORMAT_DW_OP(DW_OP_##VENDOR##_##NAME)
+
+size_t queryNumOpParams(llvm::dwarf::LocationAtom op) {
+  switch (op) {
+  case llvm::dwarf::DW_OP_addr:
+  case llvm::dwarf::DW_OP_const1u:
+  case llvm::dwarf::DW_OP_const1s:
+  case llvm::dwarf::DW_OP_const2u:
+  case llvm::dwarf::DW_OP_const2s:
+  case llvm::dwarf::DW_OP_const4u:
+  case llvm::dwarf::DW_OP_const4s:
+  case llvm::dwarf::DW_OP_const8u:
+  case llvm::dwarf::DW_OP_const8s:
+  case llvm::dwarf::DW_OP_constu:
+  case llvm::dwarf::DW_OP_consts:
+  case llvm::dwarf::DW_OP_pick:
+  case llvm::dwarf::DW_OP_plus_uconst:
+  case llvm::dwarf::DW_OP_bra:
+  case llvm::dwarf::DW_OP_skip:
+  case llvm::dwarf::DW_OP_breg0:
+  case llvm::dwarf::DW_OP_breg1:
+  case llvm::dwarf::DW_OP_breg2:
+  case llvm::dwarf::DW_OP_breg3:
+  case llvm::dwarf::DW_OP_breg4:
+  case llvm::dwarf::DW_OP_breg5:
+  case llvm::dwarf::DW_OP_breg6:
+  case llvm::dwarf::DW_OP_breg7:
+  case llvm::dwarf::DW_OP_breg8:
+  case llvm::dwarf::DW_OP_breg9:
+  case llvm::dwarf::DW_OP_breg10:
+  case llvm::dwarf::DW_OP_breg11:
+  case llvm::dwarf::DW_OP_breg12:
+  case llvm::dwarf::DW_OP_breg13:
+  case llvm::dwarf::DW_OP_breg14:
+  case llvm::dwarf::DW_OP_breg15:
+  case llvm::dwarf::DW_OP_breg16:
+  case llvm::dwarf::DW_OP_breg17:
+  case llvm::dwarf::DW_OP_breg18:
+  case llvm::dwarf::DW_OP_breg19:
+  case llvm::dwarf::DW_OP_breg20:
+  case llvm::dwarf::DW_OP_breg21:
+  case llvm::dwarf::DW_OP_breg22:
+  case llvm::dwarf::DW_OP_breg23:
+  case llvm::dwarf::DW_OP_breg24:
+  case llvm::dwarf::DW_OP_breg25:
+  case llvm::dwarf::DW_OP_breg26:
+  case llvm::dwarf::DW_OP_breg27:
+  case llvm::dwarf::DW_OP_breg28:
+  case llvm::dwarf::DW_OP_breg29:
+  case llvm::dwarf::DW_OP_breg30:
+  case llvm::dwarf::DW_OP_breg31:
+  case llvm::dwarf::DW_OP_regx:
+  case llvm::dwarf::DW_OP_fbreg:
+  case llvm::dwarf::DW_OP_piece:
+  case llvm::dwarf::DW_OP_deref_size:
+  case llvm::dwarf::DW_OP_xderef_size:
+  case llvm::dwarf::DW_OP_call2:
+  case llvm::dwarf::DW_OP_call4:
+  case llvm::dwarf::DW_OP_call_ref:
+  case llvm::dwarf::DW_OP_addrx:
+  case llvm::dwarf::DW_OP_constx:
+  case llvm::dwarf::DW_OP_convert:
+  case llvm::dwarf::DW_OP_reinterpret:
+    return 1;
+  case llvm::dwarf::DW_OP_bregx:
+  case llvm::dwarf::DW_OP_bit_piece:
+  case llvm::dwarf::DW_OP_implicit_value:
+  case llvm::dwarf::DW_OP_implicit_pointer:
+  case llvm::dwarf::DW_OP_entry_value:
+  case llvm::dwarf::DW_OP_regval_type:
+  case llvm::dwarf::DW_OP_deref_type:
+  case llvm::dwarf::DW_OP_xderef_type:
+    return 2;
+  case llvm::dwarf::DW_OP_const_type:
+    return 3;
+  default:
+    return 0;
+  }
+}
+
+::mlir::Attribute DIExpressionAttr::parse(AsmParser &parser, Type type) {
----------------
gysit wrote:

I think I agree with the goal of being in sync with LLVM and defining 200 different attributes does not sound like a good idea! 

>From the examples in the PR, I got the understanding that a DIExpression is a list of opcodes (that have a name which we should have in an enum or similar) and of integers. So the primary problem to solve is how we want to pretty print the opcodes. Do you think LLVM_DIParameter or a slightly modified class could work for this? I guess the question is if LLVM provides a method that can be used to parse and print the opcode.

Once we have a way to express an opcode inside an attribute, we could define one attribute:

```
def LLVM_DIExpressionElemAttr : LLVM_Attr<"DIExpressionElem", "di_expression_elem"> {
  let parameters = (ins
    LLVM_DIExpresionOpcode:$opcode,
    OptionalArrayRefParameter<"int64_t">:$arguments
  );
```
Ah DIExpression would then be a list of such DIExpressionElemAttr.

Could something like this make sense? Or are the integers not really bound to the opcode before? 

I assume that this complicates the import and export a little bit since the underlying structure does not exactly match. 

https://github.com/llvm/llvm-project/pull/73367


More information about the Mlir-commits mailing list