I'm not sure what semantics we might eventually want for vector <=>, but let's
give a sorry for now. Tested x86_64-pc-linux-gnu, applying to trunk. --- gcc/cp/typeck.c | 7 +++++++ gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C | 11 +++++++++++ 2 files changed, 18 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c index 124d16a31fb..ff603f3d8d9 100644 --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -5224,6 +5224,13 @@ cp_build_binary_op (const op_location_t &location, "types %qT and %qT", type0, type1); } + if (resultcode == SPACESHIP_EXPR) + { + if (complain & tf_error) + sorry_at (location, "three-way comparison of vectors"); + return error_mark_node; + } + /* Always construct signed integer vector type. */ intt = c_common_type_for_size (GET_MODE_BITSIZE (SCALAR_TYPE_MODE (TREE_TYPE (type0))), 0); diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C new file mode 100644 index 00000000000..83547691118 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C @@ -0,0 +1,11 @@ +// { dg-do compile { target c++2a } } + +#include <compare> + +#define vector __attribute__((vector_size(4*sizeof(int)) )) + +int main() +{ + vector int a, b; + a <=> b; // { dg-message "three-way comparison of vector" } +} base-commit: f15dc29a9734e360497f5bb40be6b25dcbc11645 -- 2.18.1 |
On Tue, Nov 12, 2019 at 5:54 AM Jason Merrill <[hidden email]> wrote:
> > I'm not sure what semantics we might eventually want for vector <=>, but let's > give a sorry for now. Given our vector extension does elementwise comparisons I don't think we can implement <=> in a reasonable manner. What we could eventually do is specify that <=> works on the whole vector, but then only unordered compares are easy to define there... So I think an error is more appropriate here, sorry indicates that we're just not implementing it. Richard. > Tested x86_64-pc-linux-gnu, applying to trunk. > > --- > gcc/cp/typeck.c | 7 +++++++ > gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C | 11 +++++++++++ > 2 files changed, 18 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C > > diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c > index 124d16a31fb..ff603f3d8d9 100644 > --- a/gcc/cp/typeck.c > +++ b/gcc/cp/typeck.c > @@ -5224,6 +5224,13 @@ cp_build_binary_op (const op_location_t &location, > "types %qT and %qT", type0, type1); > } > > + if (resultcode == SPACESHIP_EXPR) > + { > + if (complain & tf_error) > + sorry_at (location, "three-way comparison of vectors"); > + return error_mark_node; > + } > + > /* Always construct signed integer vector type. */ > intt = c_common_type_for_size > (GET_MODE_BITSIZE (SCALAR_TYPE_MODE (TREE_TYPE (type0))), 0); > diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C > new file mode 100644 > index 00000000000..83547691118 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C > @@ -0,0 +1,11 @@ > +// { dg-do compile { target c++2a } } > + > +#include <compare> > + > +#define vector __attribute__((vector_size(4*sizeof(int)) )) > + > +int main() > +{ > + vector int a, b; > + a <=> b; // { dg-message "three-way comparison of vector" } > +} > > base-commit: f15dc29a9734e360497f5bb40be6b25dcbc11645 > -- > 2.18.1 > |
On Tue, Nov 12, 2019 at 09:10:58AM +0100, Richard Biener wrote:
> On Tue, Nov 12, 2019 at 5:54 AM Jason Merrill <[hidden email]> wrote: > > > > I'm not sure what semantics we might eventually want for vector <=>, but let's > > give a sorry for now. > > Given our vector extension does elementwise comparisons I don't think we can > implement <=> in a reasonable manner. Why? We indeed can't return a vector of std::strong_ordering or std::partial_ordering classes, but we could return a vector of either the underlying integral values (0/1/-1/-127), or vector of enums from which one could construct those std::strong_ordering or std::partial_ordering classes. We do not support vectors of pointers and so the only possibilities are strong orderings for integral vectors and partial orderings for floating point vectors. Jakub |
On Tue, Nov 12, 2019 at 10:02 AM Jakub Jelinek <[hidden email]> wrote:
> > On Tue, Nov 12, 2019 at 09:10:58AM +0100, Richard Biener wrote: > > On Tue, Nov 12, 2019 at 5:54 AM Jason Merrill <[hidden email]> wrote: > > > > > > I'm not sure what semantics we might eventually want for vector <=>, but let's > > > give a sorry for now. > > > > Given our vector extension does elementwise comparisons I don't think we can > > implement <=> in a reasonable manner. > > Why? We indeed can't return a vector of std::strong_ordering or > std::partial_ordering classes, but we could return a vector of either the > underlying integral values (0/1/-1/-127), or vector of enums from which one > could construct those std::strong_ordering or std::partial_ordering classes. > We do not support vectors of pointers and so the only possibilities are > strong orderings for integral vectors and partial orderings for floating > point vectors. But how to we actually emit (efficient) code for this? A vector extension should produce (efficient) vector code. So unless there's convincing use-cases I'm not sure we need to do anything here. In fact other unsupported operations on vectors produce errors, not sorry(). Richard. > > Jakub > |
On Tue, Nov 12, 2019 at 10:19:49AM +0100, Richard Biener wrote:
> On Tue, Nov 12, 2019 at 10:02 AM Jakub Jelinek <[hidden email]> wrote: > > > > On Tue, Nov 12, 2019 at 09:10:58AM +0100, Richard Biener wrote: > > > On Tue, Nov 12, 2019 at 5:54 AM Jason Merrill <[hidden email]> wrote: > > > > > > > > I'm not sure what semantics we might eventually want for vector <=>, but let's > > > > give a sorry for now. > > > > > > Given our vector extension does elementwise comparisons I don't think we can > > > implement <=> in a reasonable manner. > > > > Why? We indeed can't return a vector of std::strong_ordering or > > std::partial_ordering classes, but we could return a vector of either the > > underlying integral values (0/1/-1/-127), or vector of enums from which one > > could construct those std::strong_ordering or std::partial_ordering classes. > > We do not support vectors of pointers and so the only possibilities are > > strong orderings for integral vectors and partial orderings for floating > > point vectors. > > But how to we actually emit (efficient) code for this? A vector extension > should produce (efficient) vector code. For integers perhaps: typedef int V __attribute__((vector_size(16))); V spaceship (V x, V y) { return (x < y) | ((x > y) & (V) { 1, 1, 1, 1 }); } or vpcmpgtd %xmm1, %xmm0, %xmm2 vpcmpgtd %xmm0, %xmm1, %xmm0 vpand .LC0(%rip), %xmm2, %xmm2 vpor %xmm0, %xmm2, %xmm0 for -mavx? Sure, for floating point it might be longer without -ffast-math, though scalar floating <=> doesn't expand to something short either. I believe it is something like x == y ? 0 : x < y ? -1 : x > y ? 1 : -127 so for float it could be something like (not sure about qNaNs and exceptions for either scalar or vector) vcmplt_oqps | (vcmpgt_oqps & {1,1,1,1}) \ | (vcmpunordps & {-127,-127,-127,-127})? Jakub |
On Tue, Nov 12, 2019 at 10:52 AM Jakub Jelinek <[hidden email]> wrote:
> > On Tue, Nov 12, 2019 at 10:19:49AM +0100, Richard Biener wrote: > > On Tue, Nov 12, 2019 at 10:02 AM Jakub Jelinek <[hidden email]> wrote: > > > > > > On Tue, Nov 12, 2019 at 09:10:58AM +0100, Richard Biener wrote: > > > > On Tue, Nov 12, 2019 at 5:54 AM Jason Merrill <[hidden email]> wrote: > > > > > > > > > > I'm not sure what semantics we might eventually want for vector <=>, but let's > > > > > give a sorry for now. > > > > > > > > Given our vector extension does elementwise comparisons I don't think we can > > > > implement <=> in a reasonable manner. > > > > > > Why? We indeed can't return a vector of std::strong_ordering or > > > std::partial_ordering classes, but we could return a vector of either the > > > underlying integral values (0/1/-1/-127), or vector of enums from which one > > > could construct those std::strong_ordering or std::partial_ordering classes. > > > We do not support vectors of pointers and so the only possibilities are > > > strong orderings for integral vectors and partial orderings for floating > > > point vectors. > > > > But how to we actually emit (efficient) code for this? A vector extension > > should produce (efficient) vector code. > > For integers perhaps: > typedef int V __attribute__((vector_size(16))); > > V > spaceship (V x, V y) > { > return (x < y) | ((x > y) & (V) { 1, 1, 1, 1 }); > } > or > vpcmpgtd %xmm1, %xmm0, %xmm2 > vpcmpgtd %xmm0, %xmm1, %xmm0 > vpand .LC0(%rip), %xmm2, %xmm2 > vpor %xmm0, %xmm2, %xmm0 > for -mavx? Sure, for floating point it might be longer without -ffast-math, > though scalar floating <=> doesn't expand to something short either. > I believe it is something like > x == y ? 0 : x < y ? -1 : x > y ? 1 : -127 > so for float it could be something like (not sure about qNaNs and exceptions > for either scalar or vector) > vcmplt_oqps | (vcmpgt_oqps & {1,1,1,1}) \ > | (vcmpunordps & {-127,-127,-127,-127})? Hmm, OK. Since we don't have SPACESHIP_EXPR in GIMPLE the FE has to lower it so indeed the above could be done. Then (vector <=> vector)[i] should be equal to vector[i] <=> vector[i] as well? Richard. > Jakub > |
Free forum by Nabble | Edit this page |