<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 4:26 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In particular, this is the conf I have in my script:<br>
<br>
cmake -GNinja<br>
-DCMAKE_C_COMPILER=/home/<wbr>davide/work/llvm-monorepo/<wbr>build-release/bin/clang<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></blockquote><div><br></div><div>What CMake version? Maybe this issue has been fixed in newer CMake's.</div><div><br></div><div>-- Sean Silva</div><div> </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"><br>
On Thu, May 4, 2017 at 4:24 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>> 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>> 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>> 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>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> On Wed, May 3, 2017 at 5:48 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:44 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> On Wed, May 3, 2017 at 5:40 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: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 seconds, so<br>
>>>>>>>>>>>>>> 0.5s to read the symbols is a double digit percentage of 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 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 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, 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 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 loss, but<br>
>>>>>>> that's in reality not the case, so I'm not convinced that we should warn on<br>
>>>>>>> it right now.<br>
>>>>>><br>
>>>>>><br>
>>>>>> I disagree: we should define what is a *correct* build setting, and<br>
>>>>>> warn if it is not honored.<br>
>>>>>> Your changing this definition here, and I doubt it'll be easy to 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 definition<br>
>>>>> what is correct (or at least what is not incorrect). But I still think that<br>
>>>>> that's beneficial for users overall. You are extremely familiar with LLVM<br>
>>>>> LTO, but ordinary developers don't know much about LLVM or build systems<br>
>>>>> compared to you. Attempting to use llvm-ar took a fair amount of time even<br>
>>>>> to me (which I hope better than the average Unix user). If we print out a<br>
>>>>> warning on every linker invocation, we'd probably be teaching users to<br>
>>>>> ignore warnings rather than let them change the build 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 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 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 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 vague, but<br>
>> I think the issue was that CMAKE_AR and CMAKE_RANLIB were not propagated to<br>
>> all configuration checks, so that some of them spuriously failed because the<br>
>> CFLAGS had -flto but the CMAKE_AR/CMAKE_RANLIB was not being 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>
</div></div></blockquote></div><br></div></div>