[llvm-dev] LLD status update and performance chart
Sean Silva via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 12 22:33:34 PST 2016
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>
More information about the llvm-dev
mailing list