search for: extra_section

...and attached to the TranslationUnitDecl. This would be, as far as I can see, the first annotation on the TranslationUnit level. Attributes seem to me the best solution at that point, since there is already a good infrastructure in clang. TranslationUnitDecl | NamedMetadataAttr implicit llvm.extra_section clang.analysis "Information" The clang CodeGen then generates a named metadata node on the llvm::Module level: !llvm.extra_sections = {!0} !0 = !{!"clang.analysis", !"Information"} The attached patch, then takes all key-value pairs from the named llvm.extra_se...

...tionUnitDecl. This would be, as far as I can see, the first > annotation on the TranslationUnit level. Attributes seem to me the best > solution at that point, since there is already a good infrastructure in > clang. > > TranslationUnitDecl > | NamedMetadataAttr implicit llvm.extra_section clang.analysis "Information" > > The clang CodeGen then generates a named metadata node on the > llvm::Module level: > > !llvm.extra_sections = {!0} > !0 = !{!"clang.analysis", !"Information"} > > The attached patch, then takes all key-va...

...very > specifc use case (mine): attaching single strings. I think, furthermore, > that it would also be handy to materialize and retrieve more complex > metadata types to/from object files. For example, we could serialize > LLVM metadata trees into separate sections: > > !llvm.extra_sections = {!0} > !0 = !{!"clang.myanalysis", !1, !2} > !1 = !{ i32 15, i32 28, i32 142} > !2 = !{!"key", i32 10000, !"key2", i32 9999} > > I'm not sure whether this would be useful and reusable for others. So: > Do you think this would be useful f...