[lld][COFF] LLD does not deduplicate common symbols link link.exe does

[jcranmer-intel]

Given these input files:

f1.ll:

@a.common = common global [1048576 x i8] zeroinitializer

define i32 @usea() {
  %ref_common = load i32, ptr @a.common
  ret i32 %ref_common
}

f2.ll:

@a.common = common global [1048576 x i8] zeroinitializer

define i32 @useb() {
  %ref_common = load i32, ptr @a.common
  ret i32 %ref_common
}

main.c:

extern int usea();
extern int useb();
int main() {
  return usea() + useb();
}

And linking using clang f1.ll f2.ll main.c -fuse-ld=lld -o windows-lld.exe (versus clang f1.ll f2.ll main.c -o windows.exe for using standard windows linker), we see a pretty big difference in the size of the data sections. With link.exe, the data section has a virtual size of 0x101c38; with lld, the virtual section has a size of 0x2027b0.

The principal cause of this blowup in size is that the space for common symbols are not deduplicated with LLD as they are in MSVC's link.exe. (There is an additional issue that the lld /map output doesn't include the size of common chunks if they're at the end of the .bss section, which makes the .bss section look "correctly-sized" if you're staring at the map file).

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: Joshua Cranmer (jcranmer-intel)

Given these input files:

f1.ll:

@<!-- -->a.common = common global [1048576 x i8] zeroinitializer

define i32 @<!-- -->usea() {
  %ref_common = load i32, ptr @<!-- -->a.common
  ret i32 %ref_common
}

f2.ll:

@<!-- -->a.common = common global [1048576 x i8] zeroinitializer

define i32 @<!-- -->useb() {
  %ref_common = load i32, ptr @<!-- -->a.common
  ret i32 %ref_common
}

main.c:

extern int usea();
extern int useb();
int main() {
  return usea() + useb();
}

And linking using clang f1.ll f2.ll main.c -fuse-ld=lld -o windows-lld.exe (versus clang f1.ll f2.ll main.c -o windows.exe for using standard windows linker), we see a pretty big difference in the size of the data sections. With link.exe, the data section has a virtual size of 0x101c38; with lld, the virtual section has a size of 0x2027b0.

The principal cause of this blowup in size is that the space for common symbols are not deduplicated with LLD as they are in MSVC's link.exe. (There is an additional issue that the lld /map output doesn't include the size of common chunks if they're at the end of the .bss section, which makes the .bss section look "correctly-sized" if you're staring at the map file).