<div dir="ltr">I think Chris originally envisioned appending linkage as a nice abstraction over all the hard parts of rigging up a custom object file section used across TUs with start and end symbols. However, that vision never came to pass, and anyway, it can be implemented entirely in Clang if we do want it. So, yeah, let's kill appending linkage.<div><br></div><div>We should stick with your "llvm.metadata.ctors" section in IR, rather than going straight to .init_array/.ctors/.CRT$XCU/MachO, so that GlobalOpt doesn't have to reason about the ~4 different ways of doing ctors.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 6, 2015 at 8:36 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looking at how unique appending linkage handling is I started<br>
wondering if we still need it at all.<br>
<br>
Now that we have sections, private linkage and comdats, I don't think we do.<br>
<br>
Things like<br>
<br>
 @llvm.global_ctors = ... { i32 A1, i32 B1, i8* C1 }, { i32 A2, i32 B2, i8* C2 }<br>
<br>
can be represented as<br>
<br>
@ctor1 = private ... { i32 A1, i32 B1 }, section<br>
"llvm.metadata.ctors", comdat $(comdat of C1).<br>
@ctor2 = private ... { i32 A2, i32 B2 }, section<br>
"llvm.metadata.ctors", comdat $(comdat of C2).<br>
<br>
Which has a few advantages:<br>
<br>
* It links just like every other IR.<br>
* It representation matches what is actually done in the object file.<br>
Currently the representation has different meaning if C is not in a<br>
comdat.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>