Page MenuHomePhabricator

[RFC] Added type trait to remove address space qualifier from type
AbandonedPublic

Authored by Anastasia on Mar 23 2020, 11:32 AM.

Details

Summary

As I am not developing libcxx, I am not familiar with the process. However, I was wondering if it makes sense to add the following feature.

Clang provides experimental support for address spaces in C++ mode that are represented as type qualifiers (following ISO/IEC JTC1 SC22 WG14 N1169 Section 5.1.2). It would be convenient to have a utility to remove address space from the type just like other qualifiers e.g. remove_cv.

It is not part of any official spec and therefore I am adding double underscore prefix to the name. Also the feature is guarded on the compilation with Clang since address spaces in C++ is currently just a Clang extension.

The need for this feature has been discussed in:
https://llvm.org/PR42033
https://reviews.llvm.org/D69938#1745766

Any feedback is valuable!

Diff Detail

Event Timeline

Anastasia created this revision.Mar 23 2020, 11:32 AM
libcxx/test/libcxx/type_traits/address_space.pass.cpp
15

Maybe a test that the address space was indeed removed ? (by looking at pointer-compatibility or so ?)

rjmccall added inline comments.Mar 24 2020, 8:34 AM
libcxx/include/type_traits
713

The precedent in C++17 is that you should provide both __remove_address_space and __remove_address_space_t.

Please make the argument an unsigned long long, we don't want to artificially restrict the range here in case the attribute accepts something wider in the future.

libcxx/test/libcxx/type_traits/address_space.pass.cpp
15

It also needs to be std::__remove_address_space<intAS2>::type, but yeah, I think something like:

static_assert(!std::is_same<intAS2, int>::value, "address-space qualifier not applied");
static_assert(std::is_same<std::__remove_address_space<intAS2>::type>::value, int>, "address-space qualifier not removed");
static_assert(std::is_same<std::__remove_address_space<const volatile intAS2>::type>::value, const volatile int>, "other qualifiers inappropriately removed");

And you should test __remove_address_space_t the same way.

EricWF requested changes to this revision.Mar 24 2020, 1:18 PM

We don't implement non-standard extensions in libc++.
Only when this trait is proposed for standardization can we consider adding it to the library

This revision now requires changes to proceed.Mar 24 2020, 1:18 PM

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

I agree with @EricWF here. Libc++ shouldn't become a repository of useful but non-standard utilities. It's useful to sometimes extend standard tools to non-standard concepts (like handling some Objective-C qualifiers when we can), but adding something new that hasn't been standardized is not really the business we want to be into.

However, @Anastasia , you could consider proposing the attribute for standardization, and if that makes the cut, then we'll be happy to implement it.

Cheers!

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Regarding (2) (although it's probably not changing the major concerns) this exact implementation also works for OpenCL because we map the address space keywords to the attributes during the parsing. However, OpenCL currently doesn't support libcxx. :(

Anastasia added a comment.EditedMar 25 2020, 9:49 AM

I agree with @EricWF here. Libc++ shouldn't become a repository of useful but non-standard utilities. It's useful to sometimes extend standard tools to non-standard concepts (like handling some Objective-C qualifiers when we can), but adding something new that hasn't been standardized is not really the business we want to be into.

However, @Anastasia , you could consider proposing the attribute for standardization, and if that makes the cut, then we'll be happy to implement it.

Cheers!

Ok, thanks for the feedback. I will certainly look into this however it may take long time. :)

Btw could we consider adding some sort of Clang specific C++ libs that would leverage the extensions that Clang supports in addition to the standard libraries? Wondering if it is something of interest to other use cases?

For address spaces, in particular, we would probably just need an additional header. We already have a header for OpenCL C that clang adds implicitly... so theoretically the same can be added for C++ for OpenCL. However, I was trying to avoid doing something that is only specific to OpenCL because I do believe a wider community can benefit from such functionality.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Regarding (2) (although it's probably not changing the major concerns) this exact implementation also works for OpenCL because we map the address space keywords to the attributes during the parsing. However, OpenCL currently doesn't support libcxx. :(

Ah, okay. Maybe it's one of the other languages that keeps its address spaces separate from address_space.

Regardless, if libc++ wants to have a policy of not adding new features that cover non-C++ features, that's a reasonable stance. libc++ should consider whether is_pointer needs a workaround for stripping address-space qualifiers, though.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Regarding (2) (although it's probably not changing the major concerns) this exact implementation also works for OpenCL because we map the address space keywords to the attributes during the parsing. However, OpenCL currently doesn't support libcxx. :(

Ah, okay. Maybe it's one of the other languages that keeps its address spaces separate from address_space.

Regardless, if libc++ wants to have a policy of not adding new features that cover non-C++ features, that's a reasonable stance.

This perfectly makes sense. However, we do have useful Clang extensions that need corresponding support in the libraries too. Particularly for address spaces we could add such functionality into an OpenCL specific headers and libs. It feels a bit unfortunate because the implementation in Clang is generic and therefore more areas could benefit from this feature. I don't know if we could consider to add some Clang extensions specific C++ libs... I understand that standardisation with ISO is valuabloe but it is not often a reality in the embedded world.

libc++ should consider whether is_pointer needs a workaround for stripping address-space qualifiers, though.

Yes, I see. I will look into this. Thanks!

Anastasia added inline comments.Dec 18 2020, 10:26 AM
libcxx/include/type_traits
713

The pattern is incorrect!

ldionne resigned from this revision.Jun 22 2021, 9:23 AM

Resigning to clean up my review queue.

Anastasia, are you still looking at this? It looks like you have a fix for your bug, but the patch never got updated.

Anastasia, are you still looking at this? It looks like you have a fix for your bug, but the patch never got updated.

It would be good to have this functionality but it seems that libc++ currently doesn't accept functionality that is not in standard C++ yet.

I am now looking at adding this pattern in the Clang headers for OpenCL. Alternatively, we can add a clang builtin for this if you think it is useful to the wider community? Other options could include adding a specific header or libs to implement address space-specific logic in C++.

Anastasia, are you still looking at this? It looks like you have a fix for your bug, but the patch never got updated.

It would be good to have this functionality but it seems that libc++ currently doesn't accept functionality that is not in standard C++ yet.

Ah, right, I'd forgotten. In that case, it would probably be best to just close this, since it has no path to acceptance.

Anastasia abandoned this revision.Jun 28 2021, 6:40 AM