llvm dev - Dec 2016 - LLD status update and performance chart

On Mon, Dec 12, 2016 at 11:42 AM, Andrew Kelley <superjoe30 at gmail.com>
wrote:
>
>
> On Mon, Dec 12, 2016 at 11:13 AM, Rafael Avila de Espindola via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
>
>> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>
>> > On 12 Dec 2016, at 03:39, Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> LLD's driver currently takes only a command line argument
strings, so
>> you need to write ELF files to a filesystem and read them back at the
>> moment.
>> >>
>> >> Theoretically, we could accept a list of command line strings
and
>> MemoryBuffer objects (instead of filenames) so that we can link
in-memory
>> ELF object files. Adding that feature shouldn't be hard.
>> >
>> > It would be nice to have a similar interface to the one in
libclang,
>> where the driver is given a map that substitutes in-memory objects for
>> specific files, so that the same command line can be used whether the
>> inputs are on disk or in memory.
>>
>> I would strongly object to expanding our "library" interface
at the
>> moment.
>>
>> Even what we currently have I think is a bad idea and a distraction
from
>> the current objective: writing an excellent stand alone linker. We
>> benefit massively from simple error and memory management.
>>
>> Once the linker is "done", we can discuss other possible uses
and their
>> costs. By "done" I mean at least having all the features we
want and
>> having replaced bfd ld in at least two freebsd architectures.
>>
>
> It seems reasonable to me to focus on this first, but do you agree that
> once lld gets to this milestone, the library API is a worthy time
> investment?
>
I'm fine as long as our API is the same as the command line. In that sense,
passing a map from filename to MemoryBuffer objects in addition to command
line arguments is fine to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/110efb55/attachment.html>

On Mon, Dec 12, 2016 at 12:46 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Dec 12, 2016 at 11:42 AM, Andrew Kelley <superjoe30 at
gmail.com>
> wrote:
>
>>
>>
>> On Mon, Dec 12, 2016 at 11:13 AM, Rafael Avila de Espindola via
llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>
>>> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>
writes:
>>>
>>> > On 12 Dec 2016, at 03:39, Rui Ueyama via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >>
>>> >> LLD's driver currently takes only a command line
argument strings, so
>>> you need to write ELF files to a filesystem and read them back at
the
>>> moment.
>>> >>
>>> >> Theoretically, we could accept a list of command line
strings and
>>> MemoryBuffer objects (instead of filenames) so that we can link
in-memory
>>> ELF object files. Adding that feature shouldn't be hard.
>>> >
>>> > It would be nice to have a similar interface to the one in
libclang,
>>> where the driver is given a map that substitutes in-memory objects
for
>>> specific files, so that the same command line can be used whether
the
>>> inputs are on disk or in memory.
>>>
>>> I would strongly object to expanding our "library"
interface at the
>>> moment.
>>>
>>> Even what we currently have I think is a bad idea and a distraction
from
>>> the current objective: writing an excellent stand alone linker. We
>>> benefit massively from simple error and memory management.
>>>
>>> Once the linker is "done", we can discuss other possible
uses and their
>>> costs. By "done" I mean at least having all the features
we want and
>>> having replaced bfd ld in at least two freebsd architectures.
>>>
>>
>> It seems reasonable to me to focus on this first, but do you agree that
>> once lld gets to this milestone, the library API is a worthy time
>> investment?
>>
>
> I'm fine as long as our API is the same as the command line. In that
> sense, passing a map from filename to MemoryBuffer objects in addition to
> command line arguments is fine to me.
>
This will also greatly facilitate certain measurements I'd like to do
w.r.t. different strategies for avoiding memory costs for input files (esp.
minor faults and dTLB costs). I've almost gotten to the point of
implementing this just to do those measurements.

-- Sean Silva

>
> _______________________________________________
> 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/20161212/dac2261e/attachment.html>

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> This will also greatly facilitate certain measurements I'd like to do
> w.r.t. different strategies for avoiding memory costs for input files (esp.
> minor faults and dTLB costs). I've almost gotten to the point of
> implementing this just to do those measurements.
If you do please keep it local. The bare minimum we have of library
support is already disproportionately painful and prevents easier sharing
with COFF. We should really not add more until the linker is done.

Cheers,
Rafael