[PATCH] D106615: [Clang][LLVM] generate btf_tag annotations for DIComposite types
Yonghong Song via Phabricator via cfe-commits
cfe-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 cfe-commits
mailing list