Questions on how to contribute

[jackmott]

First, is this project still active and relevant? Or is rust taking a different direction with SIMD?

second:

#[inline(always)]
#[target_feature = "+sse"]
pub fn _mm_sqrt_ps(a: f32x4) -> f32x4 {
    unsafe { sqrtps(a) }
}

I assume this exposes a function with the usual intel intrinsic name and signature, then the sqrtps is some built in llvm function name? Which somehow is exposed via the target_feature attribute?

Assuming this is still active and relevant I could contribute, just need to know where/how to look up the llvm function names.

[BurntSushi]

First, is this project still active and relevant? Or is rust taking a different direction with SIMD?

Yes! This repository represents my proposal-in-progress for an RFC to stabilize SIMD support in Rust's standard library.

I assume this exposes a function with the usual intel intrinsic name and signature, then the sqrtps is some built in llvm function name? Which somehow is exposed via the target_feature attribute?

Yes, you can see how sqrtps is brought in here: https://github.com/BurntSushi/stdsimd/blob/master/src/x86/sse.rs#L55-L56

The target_feature attribute says, "compile this function with SSE support." AFAIK, it's precisely the same as the __target__("...") attributes supported by Clang and gcc. For example: https://github.com/llvm-mirror/clang/blob/9a8f2b19b0416f6c10976342560479b45eb15724/lib/Headers/xmmintrin.h#L43

Assuming this is still active and relevant I could contribute, just need to know where/how to look up the llvm function names.

Contributions are welcome to fill out the vendor intrinsic APIs. If all goes according to plan, this will eventually get organized into a PR that goes into Rust's standard library. You can see the LLVM extern blocks in each of the files. Getting those names is trickier. I've been using this file I generated from LLVM's sources to derive the intrinsic names, and I've been following along Clang's *intrin.h headers to get hints for how to implement the intrinsics themselves.

In general, every intrinsic should have some documentation associated with them and at least one unit test. If you're working on x86, then the Intel intrinsic guide is helpful for documentation. Some of the intrinsics in Clang's header files also have documentation. (In general, I've found the Intel docs to be pretty lacking.)

[jackmott]

Thanks.
I was thinking of taking a stab at filling in AVX2, would that make sense or are there other things that should be addressed first?

[BurntSushi]

@jackmott Nope that makes sense to me! I very much want AVX/AVX2 myself as well and was hoping to have that done for the initial PR. So that would be a big help!

[jackmott]

Can you explain simd.rs a little bit?

[BurntSushi]

@jackmott Those are intrinsics defined by rustc, which in turn use LLVM intrinsics. They are described briefly at a high level in the RFC that introduced them: https://github.com/rust-lang/rfcs/blob/master/text/1199-simd-infrastructure.md The actual translation in rustc is done here: https://github.com/rust-lang/rust/blob/6d841da4a0d7629f826117f99052e3d4a7997a7e/src/librustc_trans/intrinsic.rs#L933

If you take a look at my work on the SSE2 intrinsics, you'll see that I try to avoid using the simd_* platform intrinsics directly to keep them encapsulated. For example, instead of using simd_add, I'd use the Add implementation on the specific SIMD types. No need to be religious about it though!

[jackmott]

got it.
Hope you don't mind me asking tons of questions, I'm still new to Rust.
The macros that do the operator overloading for the vector types, will that end up being exposed to consumers of the api, or is it for internal use only?

[BurntSushi]

No problem! Questions are good.

The macros themselves wouldn't be exposed, no. But the SIMD vector types along with the Add impls and such is definitely in my plan to expose. Whether that all shakes out isn't quite clear, since this still has to go through the RFC process. But there has been a lot of discussion about this on the internals forum, and my feeling is that this is pretty representative of the closest thing to a consensus that we have.

If you want to see the "public" API, then just run cargo doc and then $BROWSER target/doc/ and follow the yellow brick road to index.html. This should be much easier to read than following the macro soup.

[jackmott]

the allintrinsics document is fascinating. starting to make sense of it.
My plan would be to just to just go here:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX2&expand=3

and go down 1 by 1, refer to the allintrinsics link, add it to avx2.rs, and then on to the next.

Maybe figure out a way to codegen?? :D

[BurntSushi]

@jackmott Yeah that's pretty much what I do, although I use the XML file from Intel's web site directly: https://software.intel.com/sites/landingpage/IntrinsicsGuide/files/data-3.3.16.xml I also sometimes look at Clang's headers for hints.

Maybe figure out a way to codegen?? :D

There's been a lot of talk about that but I'm skeptical. Maybe there's a way, but I'd much rather at least one human apply individual scrutiny to the type signatures of each function. Writing them out is a good forcing function for that. I say this because it's important to get all of the vector types correct. The Intel definitions don't tell you the right integer types to use (there's only __m128, __m128d and __m128i). You might be able to infer some patterns based on the names of the intrinsics, but in my experience there are sometimes exceptions...

[jackmott]

allright, I think I've added my first avx2 intrinsic, it builds anyway, mind a quick double check?

https://github.com/jackmott/stdsimd/blob/master/src/x86/avx2.rs

also had to add avx2 to the mod.rs:

https://github.com/jackmott/stdsimd/blob/master/src/x86/mod.rs

[BurntSushi]

At a brief glance, that looks fine, although I didn't check it against the reference material. Note though that docs/tests should still be added, and I think there are some unused use statements there?

[jackmott]

how do I run the tests?
edit:
looks like just cargo test? TOO EASY!

[jackmott]

for avx2 add, I'm not seeing a 1-1 correspondence between the intel guide and the llvm intrinsics, like no add for i64 for instance. Does LLVM just not support all of them? Or is the document possibly missing some?

hmm I see them here:
https://clang.llvm.org/doxygen/avx2intrin_8h_source.html

oh this is because those are already part of the type right?

[BurntSushi]

@jackmott The tricky thing about this stuff is that a vendor intrinsic doesn't necessary map to a compiler intrinsic. Basically, as LLVM has been making their code generation better, they've been removing intrinsics that they can recognize perfectly in the code itself. So if x and y are 256 bit vector types and you add them together, then LLVM will automatically insert the right intrinsic. Here's an interesting example: https://github.com/BurntSushi/stdsimd/blob/master/src/x86/sse2.rs#L1150-L1156

This does have weird repercussions. For example, when compiling in debug mode, you probably won't end up with the desired CPU instruction. You essentially need to compile with optimizations on to get the right instruction.