Zachary Turner via llvm-dev
2017-Jun-04 17:50 UTC
[llvm-dev] Should we split llvm Support and ADT?
Fair enough, i sort of regret mentioning that specific method of splitting originally. 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 On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote:> > > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > > > 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? > > 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. > > Splitting libsupport as a whole out into its own llvm subproject has come > up many times though, and does make a lot of sense. > > -Chris > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170604/0f8333e7/attachment.html>
Zachary Turner via llvm-dev
2017-Jul-05 17:38 UTC
[llvm-dev] Should we split llvm Support and ADT?
So, here is an example of where I think a split would be really helpful. https://reviews.llvm.org/D34667 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. 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. 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. On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <zturner at google.com> wrote:> Fair enough, i sort of regret mentioning that specific method of splitting > originally. > > 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 > On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote: > >> >> > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > >> > Changing a header file somewhere and having to spend 10 minutes waiting >> for a build leads to a lot of wasted developer time. >> > >> > 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? >> >> 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. >> >> Splitting libsupport as a whole out into its own llvm subproject has come >> up many times though, and does make a lot of sense. >> >> -Chris >> >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/ca3fbfcc/attachment.html>
Justin Bogner via llvm-dev
2017-Jul-05 22:00 UTC
[llvm-dev] Should we split llvm Support and ADT?
Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes:> So, here is an example of where I think a split would be really helpful. > > https://reviews.llvm.org/D34667 > > 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. > > 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. > > 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.+1. This way of splitting things makes a ton of sense to me. The generic language support parts of ADT and Support would be useful in a number of places where we're reluctant to pull something as heavy as libSupport in.> On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <zturner at google.com> wrote: > >> Fair enough, i sort of regret mentioning that specific method of splitting >> originally. >> >> 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 >> On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote: >> >>> >>> > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> > >>> > Changing a header file somewhere and having to spend 10 minutes waiting >>> for a build leads to a lot of wasted developer time. >>> > >>> > 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? >>> >>> 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. >>> >>> Splitting libsupport as a whole out into its own llvm subproject has come >>> up many times though, and does make a lot of sense. >>> >>> -Chris >>> >>> >>> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chris Lattner via llvm-dev
2017-Jul-06 00:01 UTC
[llvm-dev] Should we split llvm Support and ADT?
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. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported, the build would set a -D flag. - StringRef.h would just include the C++’17 header and typedef StringRef to that type. - When we start requiring C++’17, someone can “StringRef”->RAUW(“std::string_view”) and nuke the header. 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. -Chris> On Jul 5, 2017, at 10:38 AM, Zachary Turner <zturner at google.com> wrote: > > So, here is an example of where I think a split would be really helpful. > > https://reviews.llvm.org/D34667 <https://reviews.llvm.org/D34667> > > 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. > > 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. > > 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. > > On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote: > Fair enough, i sort of regret mentioning that specific method of splitting originally. > > 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 > On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote: > > > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. > > > > 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? > > 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. > > Splitting libsupport as a whole out into its own llvm subproject has come up many times though, and does make a lot of sense. > > -Chris > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/c36aaef6/attachment.html>
Reid Kleckner via llvm-dev
2017-Jul-06 16:02 UTC
[llvm-dev] Should we split llvm Support and ADT?
I don't think it's a good idea to try to build the uber-portable, minimal, standard library. We already have a few of those. They are hard to modify and improve because they have too many customers with too many requirements. The sanitizer runtime libraries are complicated enough that they could also definitely benefit from a minimal LLVM support layer, but I would hate to have to maintain such a library because they have such restrictive rules against not having library dependencies. The important part of StringRef is the idea, not the code. Eventually, we'll have std::string_view, and the idea will be everywhere. On Wed, Jul 5, 2017 at 10:38 AM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> So, here is an example of where I think a split would be really helpful. > > https://reviews.llvm.org/D34667 > > 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. > > 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. > > 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. > > On Sun, Jun 4, 2017 at 10:50 AM Zachary Turner <zturner at google.com> wrote: > >> Fair enough, i sort of regret mentioning that specific method of >> splitting originally. >> >> 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 >> On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> >> wrote: >> >>> >>> > On May 26, 2017, at 5:47 PM, Zachary Turner via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> > >>> > Changing a header file somewhere and having to spend 10 minutes >>> waiting for a build leads to a lot of wasted developer time. >>> > >>> > 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? >>> >>> 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. >>> >>> Splitting libsupport as a whole out into its own llvm subproject has >>> come up many times though, and does make a lot of sense. >>> >>> -Chris >>> >>> >>> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/3b9d6296/attachment.html>