[PATCH] D32721: Accept archive files with no symbol table instad of warning on them.

[Mehdi AMINI via llvm-commits]

Clang is incrementally linking in a matter of a few seconds, so 0.5s to
read the symbols is a double digit percentage of that.
And there are over 50 binaries in LLVM, not just one.

And you still don't address the "principle of least surprise": the
configuration is *not* what is expected from the user.


-- 
Mehdi


2017-05-03 16:51 GMT-07:00 Rui Ueyama <ruiu at google.com>:

> The cost of reading symbols from object files in archive files is probably
> much cheaper than you might be thinking. If I strip all symbols from
> archives from a clang debug build, LLD takes 8.16 seconds to link, while it
> can usually link it in 7.65 seconds. So the difference is only 0.5 seconds,
> and clang is a fairly large program as a test. That test case uses ELF, but
> with Peter's patch I believe reading symbols from bitcode files is fast too.
>
> To me 0.5 seconds is too small that I want the tool to "just work" instead
> of annoy me every time I run make/ninja until I change the build
> configuration to shave off 0.5 seconds from a LTO build.
>
> On Wed, May 3, 2017 at 4:23 PM, Mehdi AMINI via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> mehdi_amini added a comment.
>>
>> I personally  think *not* warn is a terrible thing to do when there is a
>> configuration issue. Erroring is annoying, but warning should be intended
>> in such cases!
>>
>> > True, but on the other hand, it's pretty much the exact same work that
>> the archiver would need to do,
>>
>> The archiver do it once for potentially a lot of linker invocations.
>>
>> > and asking the user to change their archiver and rebuild would probably
>> consume even more time.
>>
>> This is a one time thing, and the user can live with the warning (or pass
>> a flag to disable the warning maybe) if they choose to.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D32721
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170503/de68d218/attachment.html>