[llvm-dev] Should we split llvm Support and ADT?
Zachary Turner via llvm-dev
llvm-dev at lists.llvm.org
Wed Jul 5 17:07:35 PDT 2017
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
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?
On Wed, Jul 5, 2017 at 5:01 PM Chris Lattner <clattner at nondot.org> wrote:
> 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.
> 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.
> 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
> 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
> 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>
>>> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev