[rfc] long term idea: remove appending linkage

Chris Lattner via llvm-commits llvm-commits at lists.llvm.org
Sun Dec 6 12:51:50 PST 2015


> On Dec 6, 2015, at 9:21 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> 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.

Yep that’s right.  I’m fine in principle with killing appending linkage, so long as all the current clients have moved off of it.

-Chris



> 
> On Sun, Dec 6, 2015 at 8:36 AM, Rafael Espíndola <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
> Looking at how unique appending linkage handling is I started
> wondering if we still need it at all.
> 
> Now that we have sections, private linkage and comdats, I don't think we do.
> 
> Things like
> 
>  @llvm.global_ctors = ... { i32 A1, i32 B1, i8* C1 }, { i32 A2, i32 B2, i8* C2 }
> 
> can be represented as
> 
> @ctor1 = private ... { i32 A1, i32 B1 }, section
> "llvm.metadata.ctors", comdat $(comdat of C1).
> @ctor2 = private ... { i32 A2, i32 B2 }, section
> "llvm.metadata.ctors", comdat $(comdat of C2).
> 
> Which has a few advantages:
> 
> * It links just like every other IR.
> * It representation matches what is actually done in the object file.
> Currently the representation has different meaning if C is not in a
> comdat.
> 
> Cheers,
> Rafael
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151206/ce2a4d73/attachment.html>


More information about the llvm-commits mailing list