In http://reviews.llvm.org/D9721#185342, @pcc wrote:
> The reason I made the flag link the bitcode after compilation was that I > wanted to avoid breaking any invariants that Clang's code generator might > have (e.g. if both the bitcode file and the C source file define a weak > symbol, Clang's IR generator may get confused by the presence of a duplicate > symbol, whereas the IR linker already knows to discard one of them). If > avoiding the IR linker provides a significant performance advantage, it does > seem reasonable to make `-mlink-bitcode-file` pre-populate the module, and > start fixing any assumptions we're currently making in the IR generator. Thanks, Peter. Weak symbols indeed do not work with this patch -- compiler complains about two definitions with the same mangled name. Time for plan C... http://reviews.llvm.org/D9721 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
