<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
> On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote:<br>
>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith <<br>
>> <a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br>
>><br>
>>><br>
>>>> On 2015-Aug-31, at 18:09, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <<br>
>>> <a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br>
>>>><br>
>>>>> On 2015-Aug-31, at 12:21, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
>>>>> Yep. This is where I was going :)<br>
>>>><br>
>>>> Glad I found consensus, but I want to double-check that this makes<br>
>>>> sense to add to the driver.  I didn't quite think through the<br>
>>>> implications myself.<br>
>>>><br>
>>>> Since the driver doesn't know if there's any bitcode, or if LTO is<br>
>>>> going to be invoked, it seems like I'll have to change the noasserts<br>
>>>> driver to *always* pass the option to the linker just in case we are<br>
>>>> doing LTO.  Is this reasonable?<br>
>>>><br>
>>>> Also, I realized that passing `-mllvm -disable-llvm-verifier` to ld64<br>
>>>> is redundant... so I'm thinking `-mllvm -disable-verify`.  Make<br>
>>>> sense?<br>
>>>><br>
>>>> *sigh* Reasons to hate the driver interface again...<br>
>>>><br>
>>>> I guess this is ok. Could possibly add it to the existing terrible<br>
>>> "enable this pass" interface on liblto as well.<br>
>>><br>
>>> The linker doesn't know whether clang was built with asserts, though.<br>
>>><br>
>>> We could just make it implicit: move the decision to libLTO itself.  Given<br>
>>> that clang and libLTO.dylib are different executables anyway -- and you<br>
>>> might be interposing an asserts libLTO.dylib to use with an installed clang<br>
>>> -- maybe it's even better?<br>
>>><br>
>>><br>
>> *nod* We could do that. Seems better than the alternative.<br>
><br>
> +1<br>
><br>
>>>> I don't suppose ld64 could move to a model like we're talking about with<br>
>>> lld that pcc is working on?<br>
>>><br>
>>> What specifically?<br>
>><br>
>><br>
>> Ah, using the C++ interface to handle everything and not using libLTO at<br>
>> all.<br>
>><br>
>> He can speak more to this though.<br>
><br>
> The C++ interface is much more convenient for a C++ program to use, but<br>
> clients need to revlock themselves to LLVM in order to use it.<br>
><br>
> In theory the same does not apply to libLTO, but we do end up changing it<br>
> occasionally to add new APIs which ld64 promptly starts using, so it isn't<br>
> clear how much ld64 gains by relying on libLTO,<br>
<br>
Backward/Forward compatibility?<br>
Drop any version of clang/libLTO and still be able to use the system provided linker on any version of OS X?<br>
Sounds like a valuable feature to me, which is what I believe was (is?) sought by the C API in general (but that’s another story).<br>
<br></blockquote><div><br></div><div>Static linking against the parts of llvm you care about? There's nothing in the ld64 build system that means it can't do this :)</div><div><br></div><div>And you already don't have forward compatibility because of what Peter said in the first place. :)</div><div><br></div><div>Anyhow, I don't actually expect this to change. Also the C API has to change, but yes that's a different thread.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
—<br>
Mehdi<br>
<br>
<br>
> or whether the burden on<br>
> in-tree clients is worth it (there are certainly a number of internal APIs<br>
> that are more clumsy as a result of needing to support libLTO's API; see<br>
> e.g. llvm::splitCodeGen's return value).<br>
><br>
> Thanks,<br>
> --<br>
> Peter<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div></div>