This is an archive of the discontinued LLVM Phabricator instance.

[Clang][LLVM] generate btf_tag annotations for DIDerived types
ClosedPublic

Authored by yonghong-song on Jul 22 2021, 5:23 PM.

Details

Summary

Generate btf_tag annotations for DIDrived types. More specifically,
clang frontend generates the btf_tag annotations for record
fields. The annotations are represented as an DINodeArray
in DebugInfo. The following example illustrate how
annotations are encoded in IR:

distinct !DIDerivedType(tag: DW_TAG_member, ..., annotations: !10)
!10 = !{!11, !12}
!11 = !{!"btf_tag", !"a"}
!12 = !{!"btf_tag", !"b"}

Diff Detail

Event Timeline

yonghong-song created this revision.Jul 22 2021, 5:23 PM
yonghong-song requested review of this revision.Jul 22 2021, 5:23 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJul 22 2021, 5:23 PM
  • use creation-parameters for annotations instead of replacement-style APIs.
  • fix clang-format warnings

@dblaikie could you take a look at this patch? The same as previous DIComposite patch (D106615), if the patch is accepted, I will break into llvm part and clang part and commit them separately.

dblaikie accepted this revision.Aug 20 2021, 10:36 AM

Sounds good. Please do the hasAttr/CollectBTFTagAnnotations refactor in a separate preliminary commit (cleaning up any existing callers that have the null check like that), then commit this in two parts, llvm first, then clang.

clang/lib/CodeGen/CGDebugInfo.cpp
1503–1504

could the hasAttr test be sunk into the CollectBTFTagAnnotations function? (so it's not repeated at all the callers)

This revision is now accepted and ready to land.Aug 20 2021, 10:36 AM

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.
clang/lib/CodeGen/CGDebugInfo.cpp
1503–1504

Good idea. Will change based on your suggestion.

  • put checking btf_tag existence condition in function CollectBTFTagAnnotations
This revision was landed with ongoing or failed builds.Aug 20 2021, 12:11 PM
This revision was automatically updated to reflect the committed changes.