<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2016, at 11:30 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" class="">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 11:23 AM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 13, 2016, at 11:08 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>> wrote:</div><br class="m_1491349387806721298Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini<span class="m_1491349387806721298Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="m_1491349387806721298Apple-converted-space"> </span><wbr class="">wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class="m_1491349387806721298gmail-h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 13, 2016, at 10:06 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>> wrote:</div><br class="m_1491349387806721298gmail-m_-656514987314485984Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini<span class="m_1491349387806721298Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="m_1491349387806721298Apple-converted-space"> </span><wbr class="">wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class=""><br class="">> On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">><br class="">> Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> writes:<br class="">>> This will also greatly facilitate certain measurements I'd like to do<br class="">>> w.r.t. different strategies for avoiding memory costs for input files (esp.<br class="">>> minor faults and dTLB costs). I've almost gotten to the point of<br class="">>> implementing this just to do those measurements.<br class="">><br class="">> If you do please keep it local. The bare minimum we have of library<br class="">> support is already disproportionately painful and prevents easier sharing<br class="">> with COFF. We should really not add more until the linker is done.<br class=""><br class=""></span>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.<br class=""></blockquote><div class=""><br class=""></div><div class="">LLD is a subproject of the LLVM project, but as a product, LLD itself is not LLVM nor Clang, so some technical decisions that make sense to them are not directly be applicable or even inappropriate. As a person who spent almost two years on the old LLD and 1.5 years on the new LLD, I can say that Rafael's stance on focusing on making a good linker first really makes sense. I can easily imagine that if we didn't focus on that, we couldn't make this much progress over the past 1.5 year and would be stagnated at a very basic level. Do you know if I'm a person who worked really hard on the old (and probably "modular" whatever it means) linker so hard? I'm speaking based on the experience. If you have an concrete idea how to construct a linker from smaller modules, please tell me. I still don't get what you want. We can discuss concrete proposals, but "making it (more) modular" is too vague and not really a proposal, so it cannot be a productive discussion.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote></div><div class=""><br class=""></div></div></div><div class="">I’m totally willing to believe you that it is not possible to write the fastest ELF linker on earth (or in the universe) with a library based and reusable components approach. But clang is not the fastest C/C++ compiler available, and LLVM is not the fastest compiler framework either!</div><div class=""><br class=""></div><div class="">So as a project, it seems to me that LLVM has not put the tradeoff on the speed/efficiency historically when it was to the detriment of layering/component/modularity/<wbr class="">reusability/…</div><div class=""><br class=""></div><div class="">Writing the fastest linker possible is nice goal, I regret that a LLVM subproject is putting this goal above layering/component/modularity/<wbr class="">reusability/… though.</div></div></blockquote><div class=""><br class=""></div><div class="">I've never mentioned that creating the fastest linker is the only goal.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I believe this has clearly been put *ahead* the other design aspects I mentioned, isn’t it?</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Medhi, please tell how you would *actually* layer linkers with fine-grained components.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That’s not a bait I’m gonna bite.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That's not a bait... I guess you are proposing a different architecture, so you need to explain it.</div></div></div></div></div></blockquote><div><br class=""></div><div>That’s a bait in the sense that I’m not having two months to dig into the Elf lld and write a design document/proposal for the sole purpose of making a point. And me not doing this does not impact and is not relevant to the discussion at stance..</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">You are just saying that the current LLD is worse than an imaginary super-beautiful linker.</div></div></div></div></div></blockquote></span></div><br class=""><div class="">Using superlative and trying to qualify what I’m writing with "imaginary super-beautiful linker” is just caricatural and diverting the whole point. LLVM is quite far from an "imaginary super-beautiful compiler framework”, yet it is modular and usable as a library.</div><div class=""><br class=""></div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>