[PATCH] Initial implementation of link-time optimization for the new COFF linker.

[Peter Collingbourne]

================
Comment at: COFF/SymbolTable.cpp:236
@@ +235,3 @@
+    }
+  }
+
----------------
ruiu wrote:
> On second thought, I'm now thinking that replacing DefinedBitcode symbols with regular defined symbols can be done without going through addFile. We have a list of symbols which need to be replaced, and we also have symbols in this file that should replace them. So we can just do that by overriding Symbol's Body pointers.
> 
> Not sure which is better, so it's just an idea.
> Ah, I think I understand what you are doing. LTO object file is added after all files are resolved, and at this moment we are about to add "duplicate" symbols, correct?

Correct.

> Maybe a better approach is to tweak Defined::compare so that any symbol whose type is of DefinedBitcode always "win" over any other symbols.

Do you mean that non-DefinedBitcode symbols should win over DefinedBitcode symbols? I did consider that approach to start with, but the problem with that approach is that it would prevent us from diagnosing multiply defined symbols correctly. Consider the case where a.o (bitcode) and b.o (COFF) both define a strong symbol 'foo'. When linking a.o with b.o, when we add b.o we will need to diagnose a conflict between a DefinedBitcode and a DefinedRegular. When linking a.o on its own, we have exactly the same situation when we add the LTO object, but we shouldn't diagnose.

> On second thought, I'm now thinking that replacing DefinedBitcode symbols with regular defined symbols can be done without going through addFile. We have a list of symbols which need to be replaced, and we also have symbols in this file that should replace them. So we can just do that by overriding Symbol's Body pointers.

I prefer this approach. I'm a little concerned about duplication of logic between here and `SymbolTable::resolve` (especially once we add more COFF features), but maybe that should be dealt with later if it becomes a problem.

http://reviews.llvm.org/D10115

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/