[cfe-dev] RFC: Allow non-member operator overloads for SVE types

[Chris Tetreault via cfe-dev]

   Before I say anything, I'd like to mention that I am generally in favor of having arithmetic operators defined for vector types. As a person with a background in 3d graphics, I know firsthand how irritating it can be to use named functions for arithmetic operations instead of operators. I realize the value that this feature provides.

   That said, there is a third option here: we could just not allow the operator overloads for SVE types. The unpublished ACLE spec update cited in the patch says that it's optional, we could just #define  __ARM_FEATURE_SVE_NONMEMBER_OPERATORS 0 and be done with it. This would provide the following advantages:

   1) Less divergence from the C++ standard. I'm sure this isn't the only place where we diverge.
   2) Less special case code in the compiler. Looking at the patch, it doesn't seem to be that big of a change. However, every special case we add is an increased maintenance burden.

   Leaving the operator support out has some issues as well:

   1) Awkward user code. Having to write code like auto res = add(mul(div(v1, v2), v3), neg(v4)) is painful.
   2) C++ programmers expect to be able to overload operators. I submit that most developers writing ACLE code might be able to accept that they are not writing "regular" C++ and might accept that the rules are different. They can just pretend that they're writing c code.

   Personally, I think allowing the operators is probably the way to go. The Pros seem to mainly effect the developers of Clang, and the Cons seem to mainly effect the users of Clang. I'd prefer if you did not have to define the operators in some special namespace, as I think that'll be very awkward in user code.

Thanks,
   Christopher Tetreault

-----Original Message-----
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Richard Sandiford via cfe-dev
Sent: Tuesday, March 31, 2020 9:12 AM
To: cfe-dev at lists.llvm.org
Subject: [EXT] [cfe-dev] RFC: Allow non-member operator overloads for SVE types

TL;DR: This message is an RFC about allowing non-member operator overloads to be defined for SVE types, much like enumerators.
The associated patch is https://reviews.llvm.org/D77056

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SVE types are defined to be opaque built-in types that by default can only be used via intrinsics.  One consequence of this is that the types provide no built-in versions of the unary and binary arithmetic operators.

Instead, we'd like to allow users to define non-member operators for SVE types, in much the same way as for enumeration types.
This specifically means:

* replacing "enumeration" in sections [over.match.oper] and [over.oper]
  with wording that includes both enumerations and SVE types.

* extending the enumeration handling of operator= in [over.built]
  to include SVE types.

An alternative would be to build the operators into the compiler.
However, we didn't want to do that for several reasons:

* Some of the operators would not be performance-portable.
  (E.g. %, and the 8-bit and 16-bit integer versions of /.)
  The SVE ACLE is supposed to be a low-level, almost asm-level
  interface to the architecture, so synthesising this kind of
  operation seems out-of-place.

* SVE types cannot be used in structures, so unlike with normal vector
  types, the user doesn't have the option of using a wrapper class to
  opt out of the standard handling.

* If in future we do want to provide a core group of operators in a
  standard header file/module, we could use this extension to write it.
  And if we still wanted to implement the bodies of the overloads directly
  in the compiler, we could use function attributes to achieve that.

Eli pointed out in the patch review that, unlike classes and enumerators, these built-in types don't have an obvious owner, so there was a higher risk of accidental ODR violations.  The current version of the patch therefore follows Eli's suggestion of requiring the operators to be defined in a namespace or as static functions, unless the operator also has a class or enumerator argument.

Any thoughts?  Does this seem reasonable?

Thanks,
Richard
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev