[C++ PATCH] Sorry about <=> on VECTOR_TYPE.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Jason Merrill
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

Reply | Threaded
Open this post in threaded view
|

Re: [C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Richard Biener-2
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
>
Reply | Threaded
Open this post in threaded view
|

Re: [C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Jakub Jelinek
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

Reply | Threaded
Open this post in threaded view
|

Re: [C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Richard Biener-2
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
>
Reply | Threaded
Open this post in threaded view
|

Re: [C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Jakub Jelinek
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

Reply | Threaded
Open this post in threaded view
|

Re: [C++ PATCH] Sorry about <=> on VECTOR_TYPE.

Richard Biener-2
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
>