yonghong-song added a comment.
For
> (any chance have you measured/could you measure how much larger the bitcode
> for, say, an LLVM self-host Debug build gets with all these btf patches?
> (even without targeting/using btf, this is adding an extra field to lots of
> the debug info metadata, and I'd like to know whether that makes an
> observable difference in file size))
The following are some experiments:
$ cat t.c
#define __tag1 __attribute__((btf_tag("tag1")))
struct t { int a __tag1; };
struct t g;
compilation flag: clang -O2 -g -emit-llvm -c t.c -o t.bc
Without this patch (no field annotation in record members):
1904 bytes
With this patch (no field annotation in record members):
1904 bytes
With this patch (with above field annotation in record members):
1924 bytes
If I use the code below:
#define __tag1 __attribute__((btf_tag("tag1")))
#define __tag2 __attribute__((btf_tag("tag2")))
struct t { int a __tag1 __tag2; };
struct t g;
The IR:
!8 = !DIDerivedType(tag: DW_TAG_member, name: "a", scope: !6, file: !3, line:
3, baseType: !9, size: 32, annotations: !10)
!10 = !{!11, !12}
!11 = !{!"btf_tag", !"tag1"}
!12 = !{!"btf_tag", !"tag2"}
I got 1936 bytes.
So the conclusion is:
- no overhead for bitcode size if NO annotations.
- moderate overhead for annotations. we expect btf_tag is only used in
selective places.
================
Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1503-1504
+ llvm::DINodeArray Annotations = nullptr;
+ if (field->hasAttr<BTFTagAttr>())
+ Annotations = CollectBTFTagAnnotations(field);
+
----------------
dblaikie wrote:
> could the `hasAttr` test be sunk into the `CollectBTFTagAnnotations`
> function? (so it's not repeated at all the callers)
Good idea. Will change based on your suggestion.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106616/new/
https://reviews.llvm.org/D106616
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
