<div dir="ltr">Cool. I think that's probably how we should go.<br><br><div>Thanks!</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 8, 2015 at 3:23 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was the person who originally introduced this flag in r143314. As I recall this flag was introduced in order to support linking a bitcode module containing an implementation of a runtime library for a GPU (e.g. libclc).<br>
<br>
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.<br>
<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9721&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=oFSY0-GCakbnK-gDldsnP_oEXbhzhJrBWjqh088Jt5w&s=8j8cb9wv_n1zVA7LH8kIjbQdNxNsJUAL24eDtb9_gkA&e=" target="_blank">http://reviews.llvm.org/D9721</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_settings_panel_emailpreferences_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=oFSY0-GCakbnK-gDldsnP_oEXbhzhJrBWjqh088Jt5w&s=RPRfXCe0sf3ICoHkeyPufznJYTGidiTSHNtSVpo9uNU&e=" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</blockquote></div>