<div dir="ltr">Duncan,  thanks for working on it.<div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 9:33 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
`Function` definitions should support `MDNode` attachments, with a<br>
similar syntax to instructions:<br>
<br>
    define void @foo() nounwind !attach !0 {<br>
      unreachable<br>
    }<br>
    !0 = !{}<br>
<br>
Attachments wouldn't be allowed on declarations, just definitions.<br>
<br>
There are two open problems this can help with:<br>
<br>
 1. For PGO, we need somewhere to attach the function entry count.<br>
    Attaching to the function definition is a simple solution.<br>
<br>
        define void @foo() !prof !0 {<br>
          unreachable<br>
        }<br>
        !0 = !{i32 987}<br>
<br>
 2. In debug info, we repeatedly build up a map from `Function` to the<br>
    canonical `MDSubrogram` for it.  Keeping this mapping accurate takes<br>
    subtle logic in `lib/Linker` (see PR21910/PR22792) and it's<br>
    expensive to compute and maintain.  Attaching it directly to the<br>
    `Function` designs away the problem.<br>
<br>
        define void @foo() !dbg !0 {<br>
          unreachable<br>
        }<br>
        !0 = !MDSubprogram(name: "foo", function: void ()* @foo)<br>
<br>
Thoughts?<br>
<br>
Moving onto implementation, I'd provide the same generic API that<br>
`Instruction` has, and wouldn't bother with the "fast path" API for<br>
`!dbg`.  Moreover, the generic path wouldn't be slow.  Since there are<br>
fewer functions than instructions, we can afford to store the<br>
attachments directly on the `Function` instead of off in the<br>
`LLVMContext`.<br>
<br>
It's not clear to me just how precious memory is in `Function`; IIRC<br>
it's sitting at 168B right now for x86-64.  IMO, a `SmallVector<..., 1>`<br>
-- cost of 64B -- seems fine.  I'll start with this if I don't hear any<br>
objections; we can optimize later if necessary.<br>
<br>
Otherwise, I could hack together a custom vector-like object with the<br>
"small string" optimization.  Cost would be 16B per `Function`, with the<br>
same malloc/heap costs as `SmallVector<..., 1>`.  But I haven't seen a<br>
profile that suggests this would be worth the complexity...<br>
<br>
Any opinions?<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>