<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Rui Ueyama" <ruiu@google.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Rafael Avila de Espindola" <rafael.espindola@gmail.com>, "llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Tuesday, December 13, 2016 12:56:41 PM<br><b>Subject: </b>Re: [llvm-dev] LLD status update and performance chart<br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 10:37 AM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span class="">----- Original Message -----<br>
> From: "Rafael Avila de Espindola via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> To: "Mehdi Amini" <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>><br>
> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
</span><span class="">> Sent: Tuesday, December 13, 2016 12:10:08 PM<br>
> Subject: Re: [llvm-dev] LLD status update and performance chart<br>
><br>
</span><div><div class="h5">> Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>> writes:<br>
><br>
> >> On Dec 13, 2016, at 9:40 AM, Rafael Avila de Espindola<br>
> >> <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
> >><br>
> >> Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>> writes:<br>
> >><br>
> >>>> On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via<br>
> >>>> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >>>><br>
> >>>> Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
> >>>>> This will also greatly facilitate certain measurements I'd like<br>
> >>>>> to do<br>
> >>>>> w.r.t. different strategies for avoiding memory costs for input<br>
> >>>>> files (esp.<br>
> >>>>> minor faults and dTLB costs). I've almost gotten to the point<br>
> >>>>> of<br>
> >>>>> implementing this just to do those measurements.<br>
> >>>><br>
> >>>> If you do please keep it local. The bare minimum we have of<br>
> >>>> library<br>
> >>>> support is already disproportionately painful and prevents<br>
> >>>> easier sharing<br>
> >>>> with COFF. We should really not add more until the linker is<br>
> >>>> done.<br>
> >>><br>
> >>> This is so much in contrast with the LLVM development, I find it<br>
> >>> quite hard to see this as an acceptable position on llvm-dev.<br>
> >><br>
> >> Why? What is wrong with setting priorities and observing that what<br>
> >> library support we already have has had a disproportional cost?<br>
> ><br>
> > The library-hostile lld development goes against one the core<br>
> > principles that, I believe, drives the LLVM development: providing<br>
> > libraries and reusable components.<br>
><br>
> Because it is trying to do something fundamentally different. We are<br>
> trying to write a *program*.<br>
<br>
</div></div>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.).<br></blockquote><div><br></div><div id="DWT26932">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? </div></div></div></div></blockquote>As far as I'm concerned, your response, "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" is perfectly appropriate. We need to guide these discussions with use cases, and that's the use case that's been provided so far.<br><br>Longer term, we also should take a serious look at how to unify the functionality in LLD with that in our JIT runtime linker. Having two linkers in the LLVM project, one for use with the JIT and one for other things, seems suboptimal.<br><br>Thanks again,<br>Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>