[llvm-dev] Make LLD output COFF relocatable object file (like ELF's -r does). How much work is required to implement this?

[kyra via llvm-dev]

On 10/10/2017 11:01 PM, Rui Ueyama wrote:
> Looks like I still do not understand why a .a can be much slower than 
> a prelinked .o. As far as I understand, "ld -r" doesn't reduce amount 
> of data that much. It doesn't reduce the number of relocations, as 
> relocations in input object files are basically passed through to the 
> output. It doesn't reduce the number of symbols that much, as the 
> combined object file contains a union of all symbols appeared in the 
> input files. So, I think the amount of data in a .a is essentially the 
> same as a prelinked .o. I wonder what can make a difference in speed.
Ah, good point.

Only now have I realized that my perception of link times was formed 
when no '-split-sections'  option existed. The corresponding option was 
'-split-obs' and typical package 's static library contained thousands 
object modules.

For example:
The latest official GHC 8.2.1 release "base" package's static library 
built with '-split-objs' contains 25631 object modules. The static 
library size is 28MB, prelinked object file size is 15MB.
My own custom built GHC ghc-8.3.20170619 release "base" package's static 
library built with '-split-sections' (instead of '-split-objs') contains 
228 object modules only. The static library size is 22MB, prelinked 
object file size is 15MB.

Thus, when working with "-split-sections" libraries we won't, perhaps, 
see that big differences in link times (remember we mean GHC runtime 
linker here) between these libraries and their prelinked object 
counterparts.

Thus, perhaps, having '-r' option in COFF LLD is becoming much less 
important than I though before.

Cheers,
Kyra