[LLVMdev] Proposal: MCLinker - an LLVM integrated linker

Tang Luba lubatang at gmail.com
Tue Nov 1 11:24:12 PDT 2011


Hi, Brooks,

Since this project is helped by many BSD guys in Taiwan, one of
MCLinker's main objectives is make direct contribution to the BSD
realm. Please feel free to give us suggestions to make sure we can
achieve this goal. Any comments are appreciated.

We realized open discussion on the mailing list is necessary, and we
hope this thread can be a beginning to openly discuss the project
scope, features, the why and the how of MCLinker.

I've read the list, and here are some idea from our group.

>  - LTO framework
>  - Link time optimization against IR or machine code
>  - Support for IR in ELF
LLVM has supported LTO on bitcode, and IMHO, it may be good enough.

In GCC, LTO causes 'fat' object files, because GCC needs to serialize
IR into 'intermediate language' (IL) and compress IL in object files.
In our experience, the 'fat' object files are x10 bigger than the
original one, and slow down the linking process significantly. The
generated code can get about only 7%~13% improvement.

IMHO, LLVM provides a better solution than GCC. With LLVM, users can
compile source files and generate many small bitcodes. LTO can be
performed well when link these small bitcodes into a 'big bitcode'.
MCLinker reads the 'big bitcode' and generate EXE/DSOs.
Since the 'big bitcode' is only a little bit bigger than the generated
file, we can avoid generating the 'fat' objects and also get enough
performance improvement.

Apart from the LTO, we also have some good idea on link time
optimization. I will open another thread to discuss this later.

>  - linker scripts (or equivalent)
Linker scripts is a thorny problem. The grammar of link script
language in GNU ld is context sensitive, and hard to be implemented.
Maybe we can list the necessary requirements first, and try to define
a simpler grammar.

>  - Incremental linking
>  - GNU ld compatibility
>  - IR processing by plugin
>  - Limited non-ELF support (for boot blocks, etc)
>  - Alternative hash table support
>  - Crunching support
>  - Be fast
>  - Native cross-architecture support
>  - Multipass lookup
>  - Unit tests
>  - Coded to LLVM standards (to allow inclusion in LLVM)
>  - linker is a library
>  - C and C++ support
>  - Architecture support: i386, x86_64, ARM, PPC(64),
>  - MIPS(64), PiNaCl
>  - Possible architecture support: sparc64

We still have some idea about above features. In order to keep the
discussion easy to follow, I will discuss them in other threads.

BTW, sorry for the appearance of "Email Confidentially Notice". I
asked our IT remove it from all our emails immediately. And also sorry
for some scrambled characters in the name. I had asked all my members
should use English name.

Best regards,
Luba




More information about the llvm-dev mailing list