<div dir="ltr">What I mean is, *why* would a non-LLVM project want or need everything in Support? There is a ton of compiler-specific stuff in there. There's also file i/o stuff, string formatting, threading support, floating point support, even target specific stuff. Who needs this other than LLVM? And if the answer is "nobody" (which I suspect it is), then why should non-LLVM projects import it? "Because it's the status quo" doesn't seem like a good reason.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 8:39 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 8:14 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there actually a valid use case for using the entire Support library though?<div><br></div><div>One thing that splitting solves is that I can have StringRef and ArrayRef split up and committed by tomorrow. The same can't be said for the entire Support library :)</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Huh?</div><div><br></div><div>I'm asking what is the (remaining) use case for *any* split. unsplit is the status-quo, so I don't see how the easy of doing a split is a use case... But maybe I'm misunderstanding something...</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 7:18 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 7:14 PM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 5, 2017 at 6:46 PM, Chandler Carruth 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Having watched a similar library go through this exact evolution, I really doubt we want to make any split around "things known to be in C++ in the future"... It turns out that this is nearly impossible to predict and precludes a tremendous amount of useful utilities.<div><br></div><div>For example, there is no indication that the range helpers LLVM provides will ever end up in C++'s standard library, but they certainly seem useful for the demangler (the concrete use case cited).</div><div><div><br></div><div>What is the concrete problem with just linking the support library, in all its glory, into the demangler? Why *shouldn't* we do that? I feel like that has gotten lost (for me)....</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think it's for reuse in low-level libraries (e.g. libcxxabi).</div></div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Ok, but the challenges there seem substantially larger:</div><div><br></div><div>1) We have to fix the licensing thing (we're working on that, but it's not going to be instantaneous).</div><div><br></div><div>2) We would have to somehow "sandbox" every symbol linked into this library so that when libcxxabi itself is linked with some slightly different version of LLVM than it was built with things don't explode.</div><div><br></div><div>If we solve #1 and #2 at all, running the appropriate build steps to strip *any* unused part of the big Support library out to minimize the runtime library cost seems pretty easy. And then we can use the entire Support library, no need to split.</div><div><br></div><div>So I'm wondering what the *splitting* is solving I guess?</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- Sean Silva</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br><div class="gmail_quote"><div><div class="m_-8337374678606280329m_-9082602567851665198m_7537851711691271078m_-1557034767265588849h5"><div dir="ltr">On Wed, Jul 5, 2017 at 6:27 PM Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-8337374678606280329m_-9082602567851665198m_7537851711691271078m_-1557034767265588849h5">You mentioned that a good line to draw is one where we're adding things that are *known* to be added to c++ future. How strictly do we want to enforce this? There are lots of things have equally broad utility, but aren't necessarily known to be added to c++ in the future.<br><br>For example, all of MathExtras and StringExtras, many member functions of StringRef that are not in string_view, etc. can we still have these in the top level compatibility library? <br><br>We could still aim for interfaces that 1-to-1 match STL, but it would nice if we could have some equally low level extras to enhance these classes<br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 5:44 PM Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Sure, I guess that splitting the arrayref/stringref headers out is a fine first step.</div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On Jul 5, 2017, at 5:07 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_-8337374678606280329m_-9082602567851665198m_7537851711691271078m_-1557034767265588849m_-6185988408503802764m_7173094302709104260m_1081216528289056258Apple-interchange-newline"><div><div dir="ltr">Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front / drop_front, etc that have to be converted. Then there's some methods that aren't in string_view at all, like consume_integer(), consume_front(), etc that would have to be raised up to global functions in StringExtras. All of this can certainly be done, but it's going to be a *ton* of churn and hours spent to get it all STL-ified.<div><br></div><div>Do you consider this a blocker for doing such a split? Would it make sense to do it incrementally where we first just move StringRef et all wholesale, and then incrementally work to STL-ify the interface?<br><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 5:01 PM Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library.</div><div><br></div><div>What do you think about this as an implementation approach:</div><div><br></div><div> - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now.</div><div> - When cmake detects that C++’17 mode is supported, the build would set a -D flag.</div><div> - StringRef.h would just include the C++’17 header and typedef StringRef to that type.</div><div> - When we start requiring C++’17, someone can “StringRef”->RAUW(“std::string_view”) and nuke the header.</div><div><br></div><div>This allows us to have a clean path out of these custom types, and makes it very clear that these headers are compatibility shims that go away in the future. It also makes it clear what the division is.</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><br><div><blockquote type="cite"><div>On Jul 5, 2017, at 10:38 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_-8337374678606280329m_-9082602567851665198m_7537851711691271078m_-1557034767265588849m_-6185988408503802764m_7173094302709104260m_1081216528289056258m_-7256308973118719066m_2472445786849267652Apple-interchange-newline"><div><div dir="ltr">So, here is an example of where I think a split would be really helpful.<div><br></div><div><a href="https://reviews.llvm.org/D34667" target="_blank">https://reviews.llvm.org/D34667</a><br></div><div><br></div><div>This code would benefit vastly even from just being able to use StringRef and ArrayRef. We have other cases as well where we export some code that cannot depend on the rest of LLVM.</div><div><br></div><div>Thinking about it some, StringRef, ArrayRef, and various other things like STLExtras and iterator.h basically can be summarized as "things that are either already already planned for, or wouldn't be entirely out of place in the STL itself". For example, StringRef is std::string_view. ArrayRef is std::array_view. iterator_facade_base is a better version of std::iterator. </div><div><br></div><div>So I would drop my suggestion to split the libraries in such a way that it might benefit TableGen, and instead re-word my suggestion to include only classes such as StringRef, ArrayRef, and other STL-like utilities that can benefit utilities like our demangler etc that cannot depend on the rest of LLVM. If and when we ever require C++17 for building LLVM (a long ways away, obviously, but we might as well be forward thinking), we would certainly be able to use std::string_view and std::array_view in the demangler. So splitting things in a way such as this makes long term sense IMO.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fair enough, i sort of regret mentioning that specific method of splitting originally.<br><br>For the record, i think any splitting should make sense on its own merit without considering tablegen, and hopefully the end result of "tablegen eventually depends on less stuff" would happen naturally <br><div class="gmail_quote"><div dir="ltr">On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time.<br>
><br>
> The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn’t?<br>
<br>
In all the comments downthread, I think there is one thing that hasn't been mentioned: doing a split like this makes tblgen evolution more difficult. If libsupport was split into “used by tblgen” and “not used by tblgen” sections, and then a new tblgen feature needs to use other parts of libsupport, they’d have to be moved into the “used by tblgen” directory.<br>
<br>
Splitting libsupport as a whole out into its own llvm subproject has come up many times though, and does make a lot of sense.<br>
<br>
-Chris<br>
<br>
<br>
</blockquote></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div></div><span>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</span></blockquote></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></div></blockquote></div></div></blockquote></div>
</blockquote></div></div></blockquote></div>