[llvm-dev] LLD status update and performance chart

[James Y Knight via llvm-dev]

Thank you for writing this!

I totally agree with this characterization of the discussion as a huge
misunderstanding -- I was planning to write an email saying effectively the
same thing, except, posed more as a question. :)



On Fri, Dec 16, 2016 at 1:15 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I talked several people and found that this is more like a communication
> issue rather than a technical/philosophical issue. I believe communication
> problems won't solve themselves. As a person who is on the owners file of
> LLD, I think I need to say something about that issue. Also, I guess people
> who were just watching this thread wondered why my happy pre-holiday status
> report suddenly turned into a heated discussion, and they are probably
> still wondering what's wrong with LLD. I want to address that, too.
>
> So, as a project, there is no anti-library policy in LLD. I think this is
> the misunderstanding one side had. We already provide main-as-a-library
> feature so that you can embed the linker to your program. We as a project
> welcome other ideas to export linker features at a well-defined boundary.
> For example, I think abstracting the file system access so that you can
> hook file operations could be a well-defined, useful API for those who want
> to do in-memory linking (I expressed that opinion already in this thread).
> Just like LLVM, we won't guarantee API compatibility between releases, and
> we are unlikely to be able to expose deep internals of the linker, but as
> long as you think you found a reasonable coarse API boundary, there should
> be nothing preventing you from bringing that to the table.
>
> On the other hand, as far as I talked, no one who is on the "library" side
> requested LLD expose deep internals. This is the misunderstanding the other
> side had. If we as a project said that LLD should not support any library
> interface at all, they would be upset and speak out loudly, but again,
> that's not a project policy.
>
> So, correct me if I'm wrong, but I don't see no serious conflicts here.
> The conflict I saw in the thread is I believe superficial, and I strongly
> believe that it could have been addressed calmly and nicely if we have used
> more words to explain thoughts instead of small number of strong words.
>
> Hope this helps.
>
> Rui
>
> On Fri, Dec 16, 2016 at 1:40 AM, George Rimar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> >I am on PTO, so slow to respond.
>> >
>> >Some items that are left:
>> >
>> >* Debug fission
>> >* Single file debug fission
>> >* Range extension thunks
>> >* All of freebsd links and works
>> >* Very good performance when all that is in
>>
>> Looks we have initial version of debug fusion implemented.
>> r289790, r289810 commits from yesterday did the rest of main job I
>> believe.
>> I do not know what is "Single file debug fission" ? (quick googling gives
>> nothing and I never heard about that before I think)
>>
>> George.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161216/f96ee88d/attachment.html>