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 cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits