Altivec/VSX support

[lu-zero]

Since llvm seems to have an almost viable intrinsics support now, is it possible to expose them in rust like the neon ones?

[hlandau]

The altivec intrinsics are already exposed (vec_perm, etc.) AFAICT.

Maybe rename this to "VSX support"?

[lu-zero]

No :) the first part is getting the intrinsics then I'll need to add an adaptation layer in stdsimd to make so they behave the same on le and be.

I'm still far from getting that done. (and the amount of instructions still not mapped is larger than it should)

(yes I ended up writing the support myself...)

[gnzlbg]

So things have changed a bit. I have a branch implementing it in std::arch{powerpc, powerpcle, powerpc64, powerpc64le} following the std::arch RFC (https://github.com/gnzlbg/stdsimd/tree/altivec). The roadmap approximately looks like this:

• get CI running with portable vector types, no intrinsics:
  • powerpc,
  • powerpcle,
  • powerpc64,
  • powerpc64le
• implement one intrinsic and get CI running on:
  • powerpc,
  • powerpcle,
  • powerpc64,
  • powerpc64le
• implement all Altivec and VSX architecture-specific vector types
  • 128x1 vector types
  • all others
• figure out the API to expose Altivec and how to expose Altivec and VSX intrinsics
• actually implement all intrinsics
• automatically verify the intrinsics against the spec
• write an RFC and stabilize

The main blocker is the lack of a quality PowerPC emulator with support for altivec and VSX (qemu is giving us problems here). There are alternatives (rust-lang/stdarch#176 (comment)) but they are outside our control which means that they might be unreliable over time.

The second main blocker is that the altivec and vsx intrinsics are implemented with compiler magic in C, using function overloading (a feature not available in neither C nor Rust). That can be worked around with traits, and we can use sealed traits to avoid exposing those via std::arch - that's the approach I've pursued in the branch - but it is unclear to me if that won't be too controversial to pass the RFC process.

The third main blocker is the lack of an intrinsics specification in machine readable form that could be used for automatic verification. The only document I've found is the OpenPower architecture ISA spec in PDF and the clang / gcc C++ headers. That is, the automatic verification tool is going to either have to parse a PDF, or C++ code. Both formats are not ideal. Maybe we could use rust-bindgen to generate Rust wrappers over the C++ code and parse the Rust code instead, but those headers use vector extensions of the corresponding compilers that rust-bindgen probably cannot handle right now.

In any case, closing this issue requires a non-trivial amount of work. At least a couple of months for somebody working full-time on it.

[lu-zero]

I interacted a bit with the llvm community to see if there is a simple way to extract the information we need from the intrinsics template file.

I hadn't get through it since it involves look at llvm-tblgen and play with getIntrinsicForGCCBuiltin to extract additional information from altivec.h.

In theory we could have OpenPower document the intrinsics the way we put them in rust and have a separate chapter of the Power ISA book for us, since we will need to repeat the little-endian adaptation for the instructions with endianness-bias we might not spare a large amount of time but might be another option.

I'm quite sure @edelsohn can help us regarding having the CI running and decide which direction we can go.

[gnzlbg]

In theory we could have OpenPower document the intrinsics the way we put them in rust and have a separate chapter of the Power ISA book for us,

Does this chapter exist for C already? If so, generating it in xml or similar formats (assuming it is currently in tex or similar) might be enough for us to parse it.

[autun12]

im guessing no one is working on this at the moment?

[lu-zero]

I am, hunting people regarding the documentation took a long time.

[autun12]

Okay so the documentation isn't done then?

[lu-zero]

The agreement is that once the code is done and documented, that documentation would be deemed as reference and have a chapter in the official openpower documentation.

The existing documentation for C is not really machine-parsable and does not provide all the information we need to automatically generate conformity tests.

[autun12]

ahhhh okay. Thanks for explaining

[lu-zero]

I'll send some new code during this weekend :)