[libcxx-dev] An extension of libcxx
Richard Smith via libcxx-dev
libcxx-dev at lists.llvm.org
Tue Dec 11 12:32:12 PST 2018
+ some more people who care about CUDA support but might not be subscribed
to this list.
On Tue, 11 Dec 2018 at 09:39, JF Bastien via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:
> I’m very excited to have NVIDIA collaborate on libc++. It’s worth
> supporting your weirdo macro hack as a transitional tool.
>
> I’m especially interested in working on freestanding in clang / libc++,
> bringing the good parts of it from the current C++ standard, and working
> with you and other on the Committee to make C++23 freestanding actually
> nice (Ben Craig has been working on wg21.link/P0829R3). I hope that we
> can experiment on what’s “nice” in clang / libc++ in the next few months.
> One design constraint around freestanding: I want to make sure that clang
> can keep supporting other STL implementations.
>
> I’d like to understand if we can have a different ABI for freestanding,
> given that it’s not supported in libc++ today. This might be an opportunity
> to fix some mistakes.
>
> On “freestanding” macro, clang does the following today:
>
> if (LangOpts.Freestanding)
> Builder.defineMacro("__STDC_HOSTED__", "0");
> else
> Builder.defineMacro("__STDC_HOSTED__");
>
> Otherwise, clang’s lib/Headers do some stuff with HOSTED as well, which
> might interfere with freestanding.
>
> Good header hygiene indeed seems necessary, especially for <algorithm>.
> Louis mentioned that he was interested in looking into this.
> Louis did a survey and found the following:
>
> Freestanding in the current C++20 draft requires the following headers:
>
> <ciso646>
> <cstddef>
> <cfloat>
> <limits>
> <climits>
> <cstdint>
> <cstdlib>
> <new>
> <typeinfo>
> <exception>
> <initializer_list>
> <cstdarg>
> <type_traits>
> <atomic>
>
> Of those headers, I think the following are easy to provide with minimal
> changes to libc++ and without having to ship a libc++ shared object (or
> compiler-rt), and they use the following parts of the C Standard Library:
>
> <ciso646>: nothing
> <cstddef>: stddef.h
> <cfloat> : float.h
> <limits> : stddef.h
> <climits>: limits.h
> <cstdint>: stdint.h
> <cstdlib>: stdlib.h
> <initializer_list>: stddef.h
> <cstdarg>: stdarg.h
> <type_traits>: stddef.h
>
> As a result, I think the following are low-hanging fruit that do not
> require any runtime support AFAICT:
>
> <ciso646>
> <cstddef>
> <cfloat>
> <limits>
> <climits>
> <cstdint>
> <initializer_list>
> <type_traits>
>
> Other things we might be able to throw in with minimal effort:
>
> <bit>
> <ratio>
>
> Other things that we SHOULD be able to have, but that would require
> refactoring in libc++ (and most of them are not part of the current
> freestanding):
>
> <tuple>
> <pair>
> most if not all of <functional>
> most of <algorithm>
> <span>
> <array>
> <string_view>
> lock-free parts of <atomic>
>
>
>
>
> On Dec 10, 2018, at 9:23 PM, Olivier Giroux via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
> Hello libc++-dev,
>
> In the discussion of https://reviews.llvm.org/D55517, I mentioned that we
> are attempting a vendor variant of libcxx that uses _VSTD differently. Eric
> pointed out that I should have started here, so we could talk about design
> goals. He’s right, I’m sorry.
>
> Not one to bury the lede, I’d like to talk about a CUDA C++ standard
> library.
>
> The ultimate goal of something like that should be that most things in
> C++, if not bolted too-tightly onto the operating system, should be able to
> be passed and used between CPU and GPU. There’s no fundamental reason why
> we don’t have a big chunk of C++ working like this, *today*, if we’re
> talking about contemporary HPC-friendly GPUs. The reason we don’t have much
> is that it’s a huge pile of work and everyone has managed to avoid doing it
> so far.
>
> One exploration vehicle was shown at CppCon in September (by me, see:
> YouTube, and https://github.com/ogiroux/freestanding) and then we made
> but failed to present a more detailed poster at the LLVM dev meeting in
> October. And now we’re here. 😊
>
> After making a few exploration vehicles (2 overall, 4 for <atomic>), we
> now think we’ll create version 1 this way:
>
> 1. Wrap select libcxx <*> headers with <cuda/*> to introduce symbols
> in cuda::* instead of std::*, and…
> 1. These facilities are always heterogeneous, NORTTI, and
> NOEXCEPTIONS.
> 2. Enable users to include them *on top of* their host library
> (that being CPU only).
> 2. “Select” here means prioritizing headers in Freestanding now, or
> soon, basically the header-only facilities.
> 3. Subsequently help maintain the intersection of libcxx and
> Freestanding.
>
>
> In terms of libcxx design, we think that we could layer on this surface:
>
> - A freestanding mode, say LIBCXX_FREESTANDING, with a design goal of
> placing low-OS-coupling variants of code for facilities under this mode,
> and some agreement that Freestanding libraries have different ABI goals
> than their closest Hosted relative.
> - For example, in <atomic>, it would be preferable for Freestanding
> implementations (and users) if the *lock-in-atomic* strategy was
> used for non-lock-free atomics (instead of the *sharded-lock-table* strategy
> tucked inside __cxa_atomic_*) because that then frees the program from
> dependencies on libatomic.
> - It is my intention to contribute the code for this 3rd strategy,
> and other maintenance to <atomic>, some of which I’ve already made in my
> branch.
> - An extension point that allows std::* symbols to be put into another
> namespace, both for ABI and to co-exist.
> - This is in tension with Eric’s proposed change.
> - An extension point that allows us to tune visibility control, e.g.
> add __device__ linkage to local-linkage symbols in those headers included
> in the subset (Freestanding minimum, or the implementation-defined choice).
> - This was at one point in tension with changes Louis was making,
> but I think we’re Ok right now.
> - And, generally speaking, good header inclusion hygiene that tries to
> minimize what’s pulled into a facility’s header.
>
>
> That should isolate most of the ugly stuff in our code; version 1 will
> indeed be fairly ugly, no doubt about that. But then, hopefully, this all
> ends with libcxx gaining a new implementer!
>
> Thanks for reading, I’ll try to answer your questions as best I can.
>
> Sincerely,
>
> Olivier
>
> ------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> ------------------------------
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181211/6167b134/attachment-0001.html>
More information about the libcxx-dev
mailing list