<div dir="ltr"><div>On Thu, May 4, 2017 at 9:40 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, May 4, 2017 at 4:30 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> Then maybe -DCMAKE_RANLIB=/usr/bin/true does magic? (This conversation is an<br>
> instance why I think this feature is useful :)<br>
><br>
<br>
</span>Replying to both of you together.<br>
<br>
Sean, my cmake version is 3.6. IIRC I tried this also with 3.4 in the<br>
golden days, but I'm not 100% sure.<br>
<br>
Rui, no magic here, I think. Setting RANLIB=/usr/bin/true is just an<br>
optimization as the work by ranlib is actually done by llvm-ar. People<br>
may want to set this to a real ranlib with older versions of ar(1)<br>
from GNU binutils, but even with llvm, setting RANLIB to be<br>
llvm-ranlib shouldn't change anything.</blockquote><div><br></div><div>That explains it. I think RANLIB=/bin/true is actually a key.</div><div><br></div><div>If you forget to specify RANLIB, generated make/ninja files run /usr/bin/ranlib on archive files. That strips symbol tables from archive files containing bitcode because ranlib reconstructs symbol tables and it doesn't know anything about LLVM bitcode files.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> On Thu, May 4, 2017 at 4:28 PM, Sean Silva via llvm-commits<br>
> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, May 4, 2017 at 4:26 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>><br>
>> wrote:<br>
>>><br>
>>> In particular, this is the conf I have in my script:<br>
>>><br>
>>> cmake -GNinja<br>
>>><br>
>>> -DCMAKE_C_COMPILER=/home/<wbr>davide/work/llvm-monorepo/<wbr>build-release/bin/clang<br>
>>><br>
>>> -DCMAKE_CXX_COMPILER=/home/<wbr>davide/work/llvm-monorepo/<wbr>build-release/bin/clang++<br>
>>> -DCMAKE_C_FLAGS="-fuse-ld=gold -flto=thin"<br>
>>> -DCMAKE_CXX_FLAGS="-fuse-ld=<wbr>gold -flto=thin"<br>
>>> -DCMAKE_AR=/home/davide/work/<wbr>llvm-monorepo/build-release/<wbr>bin/llvm-ar<br>
>>> -DCMAKE_RANLIB=/usr/bin/true ../llvm<br>
>>><br>
>>> (I just build llvm/clang/lld FWIW).<br>
>><br>
>><br>
>> What CMake version? Maybe this issue has been fixed in newer CMake's.<br>
>><br>
>> -- Sean Silva<br>
>><br>
>>><br>
>>><br>
>>> On Thu, May 4, 2017 at 4:24 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>><br>
>>> wrote:<br>
>>> > On Thu, May 4, 2017 at 4:12 PM, Sean Silva via llvm-commits<br>
>>> > <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>>> >><br>
>>> >><br>
>>> >> On Thu, May 4, 2017 at 3:58 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> 2017-05-04 15:50 GMT-07:00 Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>>:<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> On Wed, May 3, 2017 at 6:28 PM, Rui Ueyama via llvm-commits<br>
>>> >>>> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>>> >>>>><br>
>>> >>>>> On Wed, May 3, 2017 at 6:12 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>><br>
>>> >>>>> wrote:<br>
>>> >>>>>><br>
>>> >>>>>><br>
>>> >>>>>><br>
>>> >>>>>> 2017-05-03 18:07 GMT-07:00 Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>>:<br>
>>> >>>>>>><br>
>>> >>>>>>> On Wed, May 3, 2017 at 5:58 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>><br>
>>> >>>>>>> wrote:<br>
>>> >>>>>>>><br>
>>> >>>>>>>><br>
>>> >>>>>>>> On Wed, May 3, 2017 at 5:51 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>><br>
>>> >>>>>>>> wrote:<br>
>>> >>>>>>>>><br>
>>> >>>>>>>>> On Wed, May 3, 2017 at 5:48 PM, Mehdi AMINI<br>
>>> >>>>>>>>> <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>><br>
>>> >>>>>>>>> wrote:<br>
>>> >>>>>>>>>><br>
>>> >>>>>>>>>><br>
>>> >>>>>>>>>> On Wed, May 3, 2017 at 5:44 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>><br>
>>> >>>>>>>>>> wrote:<br>
>>> >>>>>>>>>>><br>
>>> >>>>>>>>>>> On Wed, May 3, 2017 at 5:40 PM, Mehdi AMINI<br>
>>> >>>>>>>>>>> <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>><br>
>>> >>>>>>>>>>> wrote:<br>
>>> >>>>>>>>>>>><br>
>>> >>>>>>>>>>>><br>
>>> >>>>>>>>>>>> On Wed, May 3, 2017 at 5:26 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>><br>
>>> >>>>>>>>>>>> wrote:<br>
>>> >>>>>>>>>>>>><br>
>>> >>>>>>>>>>>>> On Wed, May 3, 2017 at 5:13 PM, Mehdi AMINI<br>
>>> >>>>>>>>>>>>> <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br>
>>> >>>>>>>>>>>>>><br>
>>> >>>>>>>>>>>>>> Clang is incrementally linking in a matter of a few<br>
>>> >>>>>>>>>>>>>> seconds, so<br>
>>> >>>>>>>>>>>>>> 0.5s to read the symbols is a double digit percentage of<br>
>>> >>>>>>>>>>>>>> that.<br>
>>> >>>>>>>>>>>>>> And there are over 50 binaries in LLVM, not just one.<br>
>>> >>>>>>>>>>>>><br>
>>> >>>>>>>>>>>>><br>
>>> >>>>>>>>>>>>> We do not support incremental linking,<br>
>>> >>>>>>>>>>>><br>
>>> >>>>>>>>>>>><br>
>>> >>>>>>>>>>>> I'm talking about ThinLTO incremental linking, which we<br>
>>> >>>>>>>>>>>> support.<br>
>>> >>>>>>>>>>><br>
>>> >>>>>>>>>>><br>
>>> >>>>>>>>>>> How can that be faster than the regular build?<br>
>>> >>>>>>>>>><br>
>>> >>>>>>>>>><br>
>>> >>>>>>>>>> Not sure what you mean: on my mac ld64 links clang in less<br>
>>> >>>>>>>>>> than 2s.<br>
>>> >>>>>>>>><br>
>>> >>>>>>>>><br>
>>> >>>>>>>>> But that is ld64. We are talking about LLD, no?<br>
>>> >>>>>>>><br>
>>> >>>>>>>><br>
>>> >>>>>>>> I don't see where you're going: lld is supposed to be fast,<br>
>>> >>>>>>>> isn't it?<br>
>>> >>>>>>>> I assume it has to be able to outspeed ld64.<br>
>>> >>>>>>>> So I'm giving you a reference of what is "a regular" build time<br>
>>> >>>>>>>> and<br>
>>> >>>>>>>> that should explain why you .5s overhead is not trivial.<br>
>>> >>>>>>><br>
>>> >>>>>>><br>
>>> >>>>>>> That is hypothetical. If LLD is already able to link Clang with<br>
>>> >>>>>>> ThinLTO in 2 seconds, it may make sense to warn on 0.5 second<br>
>>> >>>>>>> loss, but<br>
>>> >>>>>>> that's in reality not the case, so I'm not convinced that we<br>
>>> >>>>>>> should warn on<br>
>>> >>>>>>> it right now.<br>
>>> >>>>>><br>
>>> >>>>>><br>
>>> >>>>>> I disagree: we should define what is a *correct* build setting,<br>
>>> >>>>>> and<br>
>>> >>>>>> warn if it is not honored.<br>
>>> >>>>>> Your changing this definition here, and I doubt it'll be easy to<br>
>>> >>>>>> revert<br>
>>> >>>>>> in the future, which is why I don't like this.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> That's a valid concern, and this change certainly relaxes the<br>
>>> >>>>> definition<br>
>>> >>>>> what is correct (or at least what is not incorrect). But I still<br>
>>> >>>>> think that<br>
>>> >>>>> that's beneficial for users overall. You are extremely familiar<br>
>>> >>>>> with LLVM<br>
>>> >>>>> LTO, but ordinary developers don't know much about LLVM or build<br>
>>> >>>>> systems<br>
>>> >>>>> compared to you. Attempting to use llvm-ar took a fair amount of<br>
>>> >>>>> time even<br>
>>> >>>>> to me (which I hope better than the average Unix user). If we print<br>
>>> >>>>> out a<br>
>>> >>>>> warning on every linker invocation, we'd probably be teaching users<br>
>>> >>>>> to<br>
>>> >>>>> ignore warnings rather than let them change the build<br>
>>> >>>>> configuration, as it<br>
>>> >>>>> just works with a marginal performance difference.<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> In my experience (and mentioned in this thread too), changing the<br>
>>> >>>> archiver is very difficult. One necessary requirement for emitting a<br>
>>> >>>> warning<br>
>>> >>>> is that it has to be actionable.<br>
>>> >>>><br>
>>> >>>> For example, in CMake, I only know how to do it after looking at<br>
>>> >>>> Rafael's<br>
>>> >>>> <a href="https://github.com/espindola/llvm-scripts" rel="noreferrer" target="_blank">https://github.com/espindola/<wbr>llvm-scripts</a> (and I have no idea how<br>
>>> >>>> Rafael<br>
>>> >>>> figured it out).<br>
>>> >>><br>
>>> >>><br>
>>> >>> As a side note: this is suboptimal I believe, cmake has -DCMAKE_AR /<br>
>>> >>> -DCMAKE_RANLIB options (just like -DCMAKE_C_COMPILER).<br>
>>> >><br>
>>> >><br>
>>> >> IIRC, I've tried to use those and they didn't work. My memory is<br>
>>> >> vague, but<br>
>>> >> I think the issue was that CMAKE_AR and CMAKE_RANLIB were not<br>
>>> >> propagated to<br>
>>> >> all configuration checks, so that some of them spuriously failed<br>
>>> >> because the<br>
>>> >> CFLAGS had -flto but the CMAKE_AR/CMAKE_RANLIB was not being<br>
>>> >> respected.<br>
>>> >><br>
>>> ><br>
>>> > hmm, my memory is very fuzzy too but I remember self-hosting LLVM with<br>
>>> > -DCMAKE_AR=myar -DCMAKE_RANLIB=/bin/true (and maybe setting -DCMAKE_NM<br>
>>> > as well, but I'm not 100% sure). Everything went smoothly, but it's<br>
>>> > been a while so things may have changed.<br>
>>> ><br>
>>> > --<br>
>>> > Davide<br>
>>> ><br>
>>> > "There are no solved problems; there are only problems that are more<br>
>>> > or less solved" -- Henri Poincare<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Davide<br>
>>><br>
>>> "There are no solved problems; there are only problems that are more<br>
>>> or less solved" -- Henri Poincare<br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
>><br>
><br>
<br>
<br>
<br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</div></div></blockquote></div><br></div></div>