[PATCH] D22356: [ThinLTO] Perform conservative weak/linkonce resolution in distributed backend case

[Mehdi AMINI via llvm-commits]

mehdi_amini added a comment.



> > The reason is that the first link is performing linker resolution: this decision process carry some specific semantic with archives. After this resolution and the ThinLTO process, there is no reason that makes sense to me right now to repeat this process.

> 

> 

> But it shouldn't be a correctness issue to do so.


Cf answer to David by email.

> > Also, the distributed build system probably needs to handle the case where an object in the archive was not selected to be part of the link at all, won't be processed by ThinLTO, and there won't be any object to pass to the final link. I'm not sure how you're handling this with gold right now though.

> 

> 

> The gold plugin processes all the bitcode files, and gold simply tells it which symbols will be prevailing and which are preempted. So there is always a resulting object file to pass to the final link.


I don't have gold to verify, but can you confirm what happens with:

  A.cpp:
  int main() {}
  B.cpp:
  void foo() {}

when built with:

  clang -c -flto -c A.cpp B.cpp
  clang -flto A.o --start-lib B.o --end-lib -Wl,-save-temps

(Not sure what is the right options to save the LTO bitcode file).

Will B.o be sent to LTO? Will it be merged with A.o?
Similarly, repeating the process with ThinLTO, will B.o be part of the index? (That'd be a semantic break).


https://reviews.llvm.org/D22356