[PATCH] D26042: Consolidate BumpPtrAllocators.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 28 12:37:28 PDT 2016


On Fri, Oct 28, 2016 at 11:56 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
>
> Sent from my iPhone
>
> On Oct 28, 2016, at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote:
>
> On Fri, Oct 28, 2016 at 10:58 AM, Mehdi AMINI <mehdi.amini at apple.com>
> wrote:
>
>> mehdi_amini added inline comments.
>>
>>
>> ================
>> Comment at: ELF/Memory.h:31
>> +extern llvm::BumpPtrAllocator BAlloc;
>> +extern llvm::StringSaver Saver;
>> +
>> ----------------
>> ruiu wrote:
>> > mehdi_amini wrote:
>> > > Global mutable state never seems like a good idea.
>> > I disagree. It depends on what you are doing and what your program is.
>> I believe that in an ecosystem where we want to be able to evolve and
>> innovate, like the LLVM ecosystem, this prevents code reuse, modularity,
>> and future innovation. This is just unacceptable technical debt.
>> Again we had this debate about lld, but this is just another opportunity
>> to express another strong disagreement with what's going on in lld.
>>
>
> I appreciate you review my patch,
>
>
> Actually and more accurately, our fundamental high level disagreement
> prevents me from any real code review in lld.
>
> but your comment raises a vague concern which doesn't have a
> justification.
>
>
> Let's agree to disagree here.
>

I agree to agree to disagree. :)

> We do care about the LLVM ecosystem, modularity and future innovation (I
> believe you would find LLD is *very* hackable if you read the source code),
> and based on our experience and knowledge with this codebase, we agreed
> that an arena allocator-ish memory management will fit best.
>
>
> Be careful with your use of "we". You never got consensus with the way
> things went in lld.
> I'm just expressing my own disagreement here, as a reminder of this, but I
> know that I'm not the only one in the community that believe that there was
> a "steam roll" there.
>

I used "we" as LLD developers. I know that you are not the only one who
disliked the part of the current LLD's architecture, and I think I
understand why you have such concern (because, you know, I know the "best
practice"). However, there was of course a reason to choose the current
architecture. Ultimately, I hope we resolve your concern by showing that
LLD is actually extensible and best platform for future innovation. Since
we restarted the code base from scratch last year, I believe we have been
earning credit from the community by attracting more developers and showing
significant progress we haven't had seen for many years, so we are on the
way. I don't think this comment mitigate your concern, but this is what I
can say at the moment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161028/4c087909/attachment.html>


More information about the llvm-commits mailing list