<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 11:56 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPhone</div><span class="gmail-"><div><br>On Oct 28, 2016, at 11:13 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 10:58 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mehdi_amini added inline comments.<br>
<br>
<br>
================<br>
<span>Comment at: ELF/Memory.h:31<br>
+extern llvm::BumpPtrAllocator BAlloc;<br>
+extern llvm::StringSaver Saver;<br>
+<br>
----------------<br>
</span><span>ruiu wrote:<br>
> mehdi_amini wrote:<br>
> > Global mutable state never seems like a good idea.<br>
> I disagree. It depends on what you are doing and what your program is.<br>
</span>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.<br>
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.<br></blockquote><div><br></div><div>I appreciate you review my patch, </div></div></div></div></div></blockquote><div><br></div></span><div>Actually and more accurately, our fundamental high level disagreement prevents me from any real code review in lld.</div><span class="gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>but your comment raises a vague concern which doesn't have a justification. </div></div></div></div></div></blockquote><div><br></div></span><div>Let's agree to disagree here. </div></div></blockquote><div><br></div><div>I agree to agree to disagree. :)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div>
</div></blockquote><br></span><div>Be careful with your use of "we". You never got consensus with the way things went in lld. </div><div>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.</div></div></blockquote><div><br></div><div>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.</div></div></div></div>