[LLVMdev] LLD improvement plan

[Reid Kleckner]

Most of what I wanted to say has been said, but I wanted to explicitly call
out COMDAT groups as something that we want that doesn't fit the atom model
very well.

Adding first class COMDATs was necessary for implementing large parts of
the Microsoft C++ ABI, but it also turns out that it's really handy on
other platforms. We've made a number of changes to Clang's IRgen to do
things like eliminate duplicate dynamic initialization for static data
members of class templates and share code for complete, base, and deleting
destructors.

Basically, COMDAT groups are a tool that the compiler can use to change the
way things are linked without changing the linker. They allow the compiler
to add new functionality and reduce coupling between the compiler and the
linker. This is a real tradeoff worth thinking about.

I think for many platforms (Windows, Linux) Clang is not the system
compiler and we need to support efficiently linking against existing
libraries for a long time to come. There are other platforms (Mac, PS4)
with a single toolchain where controlling the linker allows adding new
functionality quickly.

I think Alex is right, we should probably meet some time and figure out
what people need and how to support both kinds of platform well.

Reid

On Fri, May 1, 2015 at 6:42 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
>
> *The atom model is not the best model for some architectures *
>
>
> The atom model is a good fit for the llvm compiler model for all
> architectures.  There is a one-to-one mapping between llvm::GlobalObject
> (e.g. function or global variable) and lld:DefinedAtom.
>
> The problem is the ELF/PECOFF file format.   (Actually mach-o is also
> section based, but we have refrained from adding complex section-centric
> features to it, so mapping it to atoms is not too hard).
>
> I’d rather see our effort put to moving ahead to an llvm based object file
> format (aka “native” format) which bypasses the impedance mismatch of going
> through ELF/COFF.
>
>
>
> *One symbol resolution model doesn’t fit all*
>
>
> Yes, the Resolver was meant to call out to the LinkingContext object to
> direct it on how to link.  Somehow that got morphed into “there should be a
> universal data model that when the Resolver process the input data, the
> right platform specific linking behavior falls out”.
>
>
> -Nick
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/78d8a587/attachment.html>