[PATCH] D23739: [LTO] Handles commons in monolithic LTO

[Peter Collingbourne via llvm-commits]

pcc added a comment.

> I don't have an easy access to gold, can you provide the IR and the resolution so that I can reproduce with llvm-lto2?


Sure:

  $ cat c1.ll
  source_filename = "c1.c"
  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  @x = common global i16 0, align 2
  $ cat c2.ll
  ; ModuleID = 'c2.o'
  source_filename = "c2.c"
  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  @x = global i32 42, align 4
  $ ~/src/llvm/ra/bin/llvm-as -o c1.o c1.ll
  $ ~/src/llvm/ra/bin/llvm-as -o c2.o c2.ll
  $ ~/src/llvm/ra/bin/llvm-lto2 c1.o -r=c1.o,x,l c2.o -r=c2.o,x,pl -o foo -save-temps
  $ ~/src/llvm/ra/bin/llvm-dis -o - foo.0.0.preopt.bc 
  ; ModuleID = 'foo.0.0.preopt.bc'
  source_filename = "ld-temp.o"
  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  @x = common global [2 x i8] zeroinitializer, align 2

> Ultimately we need a consistent story for commons, and document it clearly in the API.


I think our story for all symbols should be that there can only be a maximum of a single prevailing symbol. That would be the simplest interface/implementation on the lib/LTO side. It is sufficient for non-ELF, and (with the exception of common symbols) for ELF. There are various workarounds that ELF linkers can use for common symbols, but the implementation of those workarounds ideally shouldn't live in lib/LTO.


Repository:
  rL LLVM

https://reviews.llvm.org/D23739