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

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

> On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 
> 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.
This is so much in contrast with the LLVM development, I find it quite hard to
see this as an acceptable position on llvm-dev.

— 
Mehdio

----- Original Message -----
> From: "Mehdi Amini via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Rafael Espíndola" <rafael.espindola at gmail.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, December 13, 2016 11:28:18 AM
> Subject: Re: [llvm-dev] LLD status update and performance chart
> 
> 
> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > 
> > 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.
> 
> This is so much in contrast with the LLVM development, I find it
> quite hard to see this as an acceptable position on llvm-dev.
I agree. As a project, we should evaluate all potential contributions on their
merrits, and it seems useful to withhold judgement on software-engineering
tradeoffs until we can evaluate the code impact concretely.

 -Hal
> 
> —
> Mehdio
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Mehdi Amini <mehdi.amini at apple.com> writes:
>> On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> 
>> 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.
>
> This is so much in contrast with the LLVM development, I find it quite hard
to see this as an acceptable position on llvm-dev.
Why? What is wrong with setting priorities and observing that what
library support we already have has had a disproportional cost?

Cheers,
Rafael

On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
> >
> > 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.
>
> This is so much in contrast with the LLVM development, I find it quite
> hard to see this as an acceptable position on llvm-dev.
>
LLD is a subproject of the LLVM project, but as a product, LLD itself is
not LLVM nor Clang, so some technical decisions that make sense to them are
not directly be applicable or even inappropriate. As a person who spent
almost two years on the old LLD and 1.5 years on the new LLD, I can say
that Rafael's stance on focusing on making a good linker first really makes
sense. I can easily imagine that if we didn't focus on that, we couldn't
make this much progress over the past 1.5 year and would be stagnated at a
very basic level. Do you know if I'm a person who worked really hard on the
old (and probably "modular" whatever it means) linker so hard? I'm
speaking
based on the experience. If you have an concrete idea how to construct a
linker from smaller modules,  please tell me. I still don't get what you
want. We can discuss concrete proposals, but "making it (more)
modular" is
too vague and not really a proposal, so it cannot be a productive
discussion.

That said, I think the current our "API" to allow users call our
linker's
main function hit the sweet spot. I know at least a few LLVM-based language
developers who want to eliminate external dependencies and embed a linker
to their compilers. That's a reasonable usage, and I think allowing them to
pass a map from filename to MemoryBuffer objects makes sense, too. That
would be done without affecting the overall linker architecture. I don't
oppose to that idea, and if someone wrote a patch, I'm fine with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/c44384de/attachment.html>