[llvm-dev] LLD status update and performance chart

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 13 10:37:52 PST 2016


----- 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


More information about the llvm-dev mailing list