Duncan P. N. Exon Smith
2015-Apr-15 04:33 UTC
[LLVMdev] RFC: Metadata attachments to function definitions
`Function` definitions should support `MDNode` attachments, with a similar syntax to instructions: define void @foo() nounwind !attach !0 { unreachable } !0 = !{} Attachments wouldn't be allowed on declarations, just definitions. There are two open problems this can help with: 1. For PGO, we need somewhere to attach the function entry count. Attaching to the function definition is a simple solution. define void @foo() !prof !0 { unreachable } !0 = !{i32 987} 2. In debug info, we repeatedly build up a map from `Function` to the canonical `MDSubrogram` for it. Keeping this mapping accurate takes subtle logic in `lib/Linker` (see PR21910/PR22792) and it's expensive to compute and maintain. Attaching it directly to the `Function` designs away the problem. define void @foo() !dbg !0 { unreachable } !0 = !MDSubprogram(name: "foo", function: void ()* @foo) Thoughts? Moving onto implementation, I'd provide the same generic API that `Instruction` has, and wouldn't bother with the "fast path" API for `!dbg`. Moreover, the generic path wouldn't be slow. Since there are fewer functions than instructions, we can afford to store the attachments directly on the `Function` instead of off in the `LLVMContext`. It's not clear to me just how precious memory is in `Function`; IIRC it's sitting at 168B right now for x86-64. IMO, a `SmallVector<..., 1>` -- cost of 64B -- seems fine. I'll start with this if I don't hear any objections; we can optimize later if necessary. Otherwise, I could hack together a custom vector-like object with the "small string" optimization. Cost would be 16B per `Function`, with the same malloc/heap costs as `SmallVector<..., 1>`. But I haven't seen a profile that suggests this would be worth the complexity... Any opinions?
Diego Novillo
2015-Apr-16 14:40 UTC
[LLVMdev] RFC: Metadata attachments to function definitions
On Wed, Apr 15, 2015 at 12:33 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:> 1. For PGO, we need somewhere to attach the function entry count. > Attaching to the function definition is a simple solution. > > define void @foo() !prof !0 { > unreachable > } > !0 = !{i32 987}I've been thinking about ways of storing this information somewhere and this should be perfect for my needs. Thanks! Diego.
Xinliang David Li
2015-Apr-17 04:14 UTC
[LLVMdev] RFC: Metadata attachments to function definitions
Duncan, thanks for working on it. David On Tue, Apr 14, 2015 at 9:33 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> > `Function` definitions should support `MDNode` attachments, with a > similar syntax to instructions: > > define void @foo() nounwind !attach !0 { > unreachable > } > !0 = !{} > > Attachments wouldn't be allowed on declarations, just definitions. > > There are two open problems this can help with: > > 1. For PGO, we need somewhere to attach the function entry count. > Attaching to the function definition is a simple solution. > > define void @foo() !prof !0 { > unreachable > } > !0 = !{i32 987} > > 2. In debug info, we repeatedly build up a map from `Function` to the > canonical `MDSubrogram` for it. Keeping this mapping accurate takes > subtle logic in `lib/Linker` (see PR21910/PR22792) and it's > expensive to compute and maintain. Attaching it directly to the > `Function` designs away the problem. > > define void @foo() !dbg !0 { > unreachable > } > !0 = !MDSubprogram(name: "foo", function: void ()* @foo) > > Thoughts? > > Moving onto implementation, I'd provide the same generic API that > `Instruction` has, and wouldn't bother with the "fast path" API for > `!dbg`. Moreover, the generic path wouldn't be slow. Since there are > fewer functions than instructions, we can afford to store the > attachments directly on the `Function` instead of off in the > `LLVMContext`. > > It's not clear to me just how precious memory is in `Function`; IIRC > it's sitting at 168B right now for x86-64. IMO, a `SmallVector<..., 1>` > -- cost of 64B -- seems fine. I'll start with this if I don't hear any > objections; we can optimize later if necessary. > > Otherwise, I could hack together a custom vector-like object with the > "small string" optimization. Cost would be 16B per `Function`, with the > same malloc/heap costs as `SmallVector<..., 1>`. But I haven't seen a > profile that suggests this would be worth the complexity... > > Any opinions? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150416/2b29e52c/attachment.html>