[PATCH] D26042: Consolidate BumpPtrAllocators.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 28 13:31:45 PDT 2016


Mehdi,

I cannot design an API or set module boundaries for imaginary users because
it'd be almost always wrong and lead to overengineering. What do you have
in your mind about what you want to do with a moduler linker? I'd like to
cover your use cases (probably not now, but it should be taken into
account.)

On Fri, Oct 28, 2016 at 1:16 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> > On Oct 28, 2016, at 1:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> >
> >
> >> On Oct 28, 2016, at 1:00 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> >>
> >>> I’m fine with keeping our disagreement about the lld “style”.
> >>>
> >>> Just keep in mind that this is not a direction that is “encouraging
> everyone” to be involved or care about lld.
> >>
> >> That is fine. The objective of the new ELF linker is simple: be the
> >> best ELF linker out there. The objective is not to have it be a
> >> generic reusable framework os to maximize the number of people
> >> involved in it.
> >
> > Not being reusable just does not line up with what *I* would expect from
> a LLVM project in general. We wouldn’t have this discussion if you had
> started a separate linker project on GitHub.
>
> To be clear: I’m just expressing a personal view and expectation here:
> there is nothing wrong with building an awesome monolithic linker that
> solves real problem otherwise (which is what I believe you are doing with
> lld).
>
>> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161028/fde73afb/attachment.html>


More information about the llvm-commits mailing list