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

Mehdi Amini <mehdi.amini at apple.com> writes:
>> On Dec 13, 2016, at 9:40 AM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>> 
>> 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?
>
> The library-hostile lld development goes against one the core principles
that, I believe, drives the LLVM development: providing libraries and reusable
components.
Because it is trying to do something fundamentally different. We are
trying to write a *program*.

Cheers,
Rafael

----- Original Message -----
> From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, December 13, 2016 12:10:08 PM
> Subject: Re: [llvm-dev] LLD status update and performance chart
> 
> Mehdi Amini <mehdi.amini at apple.com> writes:
> 
> >> On Dec 13, 2016, at 9:40 AM, Rafael Avila de Espindola
> >> <rafael.espindola at gmail.com> wrote:
> >> 
> >> 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?
> >
> > The library-hostile lld development goes against one the core
> > principles that, I believe, drives the LLVM development: providing
> > libraries and reusable components.
> 
> Because it is trying to do something fundamentally different. We are
> trying to write a *program*.
But this is not a technical argument. As a project, we rarely write programs, as
such. We generally create reusable components that happen to have driver
executables. At least long term, I think there's consensus that this is the
best path. If we're going to make a different choice in this case, we need
concrete reasons. We should discuss this in the context of the reasons
you've provided (error handling, etc.).

 -Hal
> 
> Cheers,
> Rafael
> _______________________________________________
> 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

Hal Finkel <hfinkel at anl.gov> writes:
> But this is not a technical argument. As a project, we rarely write
programs, as such. We generally create reusable components that happen to have
driver executables. At least long term, I think there's consensus that this
is the best path. If we're going to make a different choice in this case, we
need concrete reasons. We should discuss this in the context of the reasons
you've provided (error handling, etc.).
We are not in a position no judge and will not be until the linker is
done. From what library support we have I think that was a horrible
mistake with a disproportionate cost.

*Once* the linker is done, if someone is able to first define what a
modular linker means, write a patch for it and show that it doesn't
degrade the linker performance or maintainability that is awesome. But
we don't have a linker yet, so, *PLEASE* let us write a linker. I don't
agree with how other parts of llvm are written but I don't keep
permanently nagging people do implement it the way *I* think is
correct.

Cheers,
Rafael

On Tue, Dec 13, 2016 at 10:37 AM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> ----- Original Message -----
> > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev
at lists.llvm.org>
> > To: "Mehdi Amini" <mehdi.amini at apple.com>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Tuesday, December 13, 2016 12:10:08 PM
> > Subject: Re: [llvm-dev] LLD status update and performance chart
> >
> > Mehdi Amini <mehdi.amini at apple.com> writes:
> >
> > >> On Dec 13, 2016, at 9:40 AM, Rafael Avila de Espindola
> > >> <rafael.espindola at gmail.com> wrote:
> > >>
> > >> 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?
> > >
> > > The library-hostile lld development goes against one the core
> > > principles that, I believe, drives the LLVM development:
providing
> > > libraries and reusable components.
> >
> > Because it is trying to do something fundamentally different. We are
> > trying to write a *program*.
>
> But this is not a technical argument. As a project, we rarely write
> programs, as such. We generally create reusable components that happen to
> have driver executables. At least long term, I think there's consensus
that
> this is the best path. If we're going to make a different choice in
this
> case, we need concrete reasons. We should discuss this in the context of
> the reasons you've provided (error handling, etc.).
>
Please tell me what you think about how reusable components would be like.
Which parts of the linker can be reusable components? Is that really
feasible? You are saying that the linker should be written in different way
by comparing it with an ideal linker (modular, reusable and fast! and by
the way the current LLD is much more reusable and extensible than before in
my opinion), but you can say anything if you compare with an ideal one. You
need to prove that it's doable so we should do that way instead of this. We
(or I) did a large experiment with the old LLD for years but couldn't find
a way to make it possible in a reasonable manner. I'm still trying to find
one, by distilling ELF and COFF linkers common parts, but still couldn't
make it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/6ed4a48a/attachment.html>