Are the alignr/alignl simd functions planned?

[Kerollmops]

Hello!

I am, and I know a lot of people are, very interested in this library and was wondering if it was planned to add the _mm_alignr_epi8 functions family? I have found this issue that lists the next features to add but mine was not listed, will maybe be added as a next step?

Thank you very much!

[Lokathor]

Seems reasonable to put in. I'm not sure how people would want to define it for things other than 128-bit size, but a guess a general byte rotation might be fine.

[bjorn3]

This is a highliy specialized instruction that is only available on x86. This makes it a bad fit for stdsimd. Stdsimd is supposed to be roughly the biggest common denominator of all platforms supported by rust. Of course LLVM is allowed to optimize a sequence of functions that behaves identical to that intrinsic to a single instruction.

[Lokathor]

Naw it's got a very clear semantics though, "rotate the value by N bytes", which makes it at worst a slightly odd shuffle. It's a reasonable helper method to have i think.

[bjorn3]

@Lokathor It isn't a byte rotate at all as far as I know. It concatenates blocks from both arguments, shifts a given amount and then takes the lower half of each block.

[thomcc]

Yeah, they're not really rotate. They're really useful where available though... I called it out a long time ago as the kind of instruction that would be useful to support but might be hard to describe semantically...

[Lokathor]

ah my mistake, i remember now, it's only a rotate if you pass the same register as both arguments.

the general two-arg form might be weird enough to be very low priority or even out of scope.

[thomcc]

This kind of thing is why I was hoping we'd land on some generalization of permutation, which would handle a lot of these styles of intrinsics... but I don't really know what that would look like.

[workingjubilee]

@Kerollmops No x86 intrinsic per se will be "added", so in a strict sense, the answer is simply No.

...but we will probably offer general APIs that do similar things. The result may be less terse, as e.g. it is quite likely we will offer safe transmutation functions that allow you to use to_ne_bytes and then do the byte rotation (and then interleaving) on your own and then cast from_ne_bytes, and hopefully LLVM will optimize that correctly. There is not actually a whole lot we can do if it doesn't, honestly, as we have a fairly limited amount of power over codegen on this end.

A generalized byte permutation in a single function seems plausible but that's going to take Some Design, especially given the obstacles we already have w/r/t shuffle APIs.

Also that intrinsic is already supported in core::arch and this sort of request reinforces why we will allow people to cast into hardware types and use such intrinsics if they need that kind of optimization.

[thomcc]

It's not bytewise, it's bitwise. to/from_ne_bytes doesn't really help.

[Lokathor]

the intel guide says

Operation
tmp[255:0] := ((a[127:0] << 128)[255:0] OR b[127:0]) >> (imm8*8)
dst[127:0] := tmp[127:0]

which seems byte-wise to me.

[thomcc]

Ah, right, hmm, my bad. There are some bitwise permutation operations but I'm mistaken here.

[Kerollmops]

Thank you very much for all your fast answers, I wasn't expecting this amount of interest here 😄

The fact that we will rely on the LLVM codegen suits me and as you say I can use the core::intrinsic function on x86.