llvm dev - Apr 2015 - [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?

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.

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>