Reduce the code size of ld.mcld - ld.lite

[GoogleCodeExporter]

ld.mcld leverages too much unnecessary LLVM libraries and grows fat. Some 
tools, such as NDK, can not provide LLVM shared library. The static LLVM 
library increase MCLinker code size significantly. I plan to make a new linker 
- ld.lite - to reduce the code size by removing some llc features.

The list of relocatable objects (sorted by size)
32M   libmcld.a
20M   ld.mcld
14M   ld.bcc
1.9M  ld_mcld-main.o
1.5M  MCLDTargetMachine.o
1.1M  GNULDBackend.o
964K  MCLinker.o
865K  MipsLDBackend.o
796K  MipsRelocator.o
740K  ld_mcld-LEB128Test.o
723K  MipsGOT.o

Original issue reported on code.google.com by LubaTang on 7 Aug 2013 at 4:07

[GoogleCodeExporter]

You mean to essentially make LTO optional?

Original comment by joerg.sonnenberger@googlemail.com on 9 Aug 2013 at 2:08

[GoogleCodeExporter]

ld.mcld will keep the ability to leverage LLVM. We can do LTO in ld.mcld. I 
plan to implement some useful IRs, such as ICFG (Interproecdural control flow 
graph), CMG (cache-manage graph) and so on. Some of these IR requires LLVM 
disassembler.

ld.lite aims to remove LLVM target machine for reducing the code size, and LLVM 
disassembler may not be used in ld.lite.

Original comment by LubaTang on 11 Aug 2013 at 9:56

[GoogleCodeExporter]

Another question: are you comparing "size" output or raw object size? It looks 
like a debug build to me.

Original comment by joerg.sonnenberger@googlemail.com on 11 Aug 2013 at 9:41

[GoogleCodeExporter]

Those are `ls -lhS`. After strip, the size become

-rwxr-xr-x  1 lubatang  staff    17M Aug 12 11:37 ld.mcld
-rwxr-xr-x  1 lubatang  staff    12M Aug 12 11:37 ld.bcc

My goal is to reduce ld.lite to 6M.

Original comment by LubaTang on 12 Aug 2013 at 3:38

[GoogleCodeExporter]

I found most code size comes from LLVM optimization passes. LLVM contains 60+ 
optimization passes and MCLinker doesn't need any of them. Unfortunately, we 
unintentionally pull them in by pulling LLVM target machines. LLVM target 
machines is used to customize the step of optimization passes. If we pull one 
of the target machine, we also pull all of the optimization passes.

MCLinker pull LLVM target machines when we initialize mcld::Target. 
mcld::Target contains a pointer to llvm::Target. When we initialize a 
mcld::Target, we will look up llvm::TargetRegistry and find the associated 
llvm::Target. llvm::TargetRegistry and llvm::Target pulls all target machines 
and grows up the code.

Therefore, one of my approach is to remove the dependency between mcld::Target 
and llvm::Target. I will let mcld::Target do not contain llvm::Target, and do 
not look up llvm::TargetRegistry for llvm::Target. This approach should reduce 
some code size.

Original comment by LubaTang on 13 Aug 2013 at 4:51

[GoogleCodeExporter]

Another option would be to investigate how the (static) linkage can pull less 
stuff in. That would benefit various other tools as well.

Original comment by joerg.sonnenberger@googlemail.com on 15 Aug 2013 at 12:15

[GoogleCodeExporter]

Agree with Joerg. Archives can pull less stuff in. However, this request has 
due day. Myself will try to separate llvm::Target and mcld::Target as the first 
step.

Original comment by LubaTang on 16 Aug 2013 at 7:18

[GoogleCodeExporter]

-rwxr-xr-x  1 lubatang  staff   1.2M Aug 29 02:55 ld.lite

Original comment by LubaTang on 28 Aug 2013 at 6:55

• Changed state: Fixed