[rfc] long term idea: remove appending linkage

[Reid Kleckner via llvm-commits]

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.

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.

On Sun, Dec 6, 2015 at 8:36 AM, Rafael Espíndola <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/02547e54/attachment.html>