[LLVMdev] RFC: Metadata attachments to function definitions

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Apr 14 21:33:03 PDT 2015


`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?




More information about the llvm-dev mailing list