[PATCH] D106615: [Clang][LLVM] generate btf_tag annotations for DIComposite types

Yonghong Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 17 16:12:23 PDT 2021


yonghong-song added inline comments.


================
Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:3478-3479
 
+  if (D->hasAttr<BTFTagAttr>())
+    RealDecl->replaceAnnotations(CollectBTFTagAnnotations(D));
+
----------------
dblaikie wrote:
> Any reason this has to be done with a replace-style API, rather than constructed when the DI node is constructed in the first place?
It looks DIComposite has quite a few replace-style API, e.g.,
```
  void replaceElements(DINodeArray Elements) {
#ifndef NDEBUG
    for (DINode *Op : getElements())
      assert(is_contained(Elements->operands(), Op) &&
             "Lost a member during member list replacement");
#endif
    replaceOperandWith(4, Elements.get());
  }

  void replaceVTableHolder(DIType *VTableHolder) {
    replaceOperandWith(5, VTableHolder);
  }

  void replaceTemplateParams(DITemplateParameterArray TemplateParams) {
    replaceOperandWith(6, TemplateParams.get());
  }
```

For example, elements is used with a replace-style API. I am using replace-style API just wanting to be similar to other similar fields, e.g., elements (DINodeArra) handling.

Actually most of DI* types do not use replace-style API (see my other diffs) and in those cases, I didn't use replace-style API.

But if you think I should put the fields directly during creation for DICompositeType, I can certainly do that. Please let me know your preference.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106615/new/

https://reviews.llvm.org/D106615



More information about the llvm-commits mailing list