Implement some arithmetic operations for `std::arch` SIMD types

[sayantn]

Proposal

Problem statement

The SIMD types in core::arch don't implement any arithmetic operators in core::ops, which makes them unwieldy and verbose to use

Motivating examples or use cases

Currently writing a simple bitwise complement of a vector type (e.g. __m256i from x86) requires considerable boilerplate

#[target_feature(enable = "avx2)]
pub fn foo(a: __m256i) -> __m256i {
    _mm256_xor_si256(a, _mm256_set1_epi64x(-1))
}

Implementing some arithmetic ops for these SIMD types will make them much easier to use. This is a popular C compiler extension, supported by gcc, clang and icc.

Solution sketch

Implement the following traits (and the assign variants, if applicable) for all SIMD types that have a defined element size (one exception is __m{128,256,512}i in x86)

• Add
• Sub
• Mul
• Div
• Rem
• Neg
• Index and IndexMut (should behave identical to indexing to the array got by transmuting) (this can be discussed, the C apis don't define this. Probably more complicated than transmuting due to ARMBE)

Along with these, integer SIMD types should also implement

• BitOr
• BitAnd
• BitXor
• Not
• Shl and Shr (if element size is defined)

Fortunately, all of these can be implemented easily (and more importantly, independent of target features) by using core::intrinsics::simd

Alternatives

• Leave this for third-party crates (i.e. crates that offer a "safe" intrinsics API, e.g. safe_arch)
• Let portable_simd handle this

Links and related work

• Add an implementation of not to __m256i and possibly other types. stdarch#1075

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[scottmcm]

I think that given that #601 (comment) was just closed as "not planned", this one probably will not be accepted either.

The types with the intrinsics are for using the intrinsics exactly as the manufacturer defined them, not for the library team to add more.

TBH, I think anything simple enough that it could stabilize on random arch types is just something that should get stabilized on std::simd::Simd.

[scottmcm]

• Index and IndexMut (should behave identical to indexing to the array got by transmuting)

Note that I would particularly suggest against this one. Those need to return references, which force the vectors into memory. And even if they could use insertvalue/extractvalue, that's frequently a poor way to work with vectors anyway.

If you want indexing, use arrays (with Simd::from_array and Simd::into_array as needed).

[sayantn]

I myself closed it, then I realized that this is a very popular C compiler extension (supported by gcc, clang, icc). These are already there on core::simd::Simd, but the problems are

• portable simd is still unstable
• using these operations through portable simd requires frequent casts and From/Into's, which defeat the purpose of this (make it less verbose to use these arch-specific SIMD types)

I also kinda agree with you on Index/IndexMut, the C apis don't define this. We can probably discuss on that

[okaneco]

Index and IndexMut (should behave identical to indexing to the array got by transmuting)

It was brought up that it's more complicated than a transmute on some platforms so these are likely a non-starter
#601 (comment)

[sayantn]

Oh, I completely forgot about ARM-BE lol

[tgross35]

portable simd is still unstable

For what it's worth there has been discussion recently about moving toward stabilization of a subset. Which is part of the motivation for closing the ACP Scott linked (#601).

[joshtriplett]

We discussed these in today's @rust-lang/libs-api meeting.

We don't want to add the Index/IndexMut operations, based on the discussion in this ACP. And from what we can tell, there isn't a Rem operation available for floating-point SIMD, so let's drop Rem as well.

Other than those, we'd like to accept this ACP. That includes the explicit caveat mentioned in the proposal that the i types on x86 should not provide the arithmetic operations, because those types are a bag of bits that don't specify an integer size.

For any given architecture, we should only add the operations that have a corresponding intrinsic on that architecture.

Please note that each architecture should get a separate PR, so that that PR can be reviewed by an expert for that target.

[Amanieu]

You can close this ACP once the tracking issue has been created.

[sayantn]

Should we fully drop Rem? The rust-native float types do have Rem implementations. Even if we don't want to do it for float SIMD, is there a problem doing it for int vectors?