[llvm-dev] Should we split llvm Support and ADT?

[Justin Bogner via llvm-dev]

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