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

[Zachary Turner via llvm-dev]

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>