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.

[jackmott]

The debug vs release thing is familiar, .NET's SIMD support does the same thing.

[jackmott]

_mm256_alignr_epi8
Any idea what this corresponds to?

Do you want me to wait till the entire avx2 is done before doing a PR?
I've got [abs,add, adds, and, andnot,avg,cmpeq,cmpgt] instructions, with comments and tests so far:

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

[jackmott]

#[allow(non_camel_case_types)]
pub type __m128i = ::v128::i8x16;

Does it matter that this is aliased to i8x16 or would anything do?
Should I use this same approach for:
__m256i _mm256_and_si256 (__m256i a, __m256i b) ?

[jackmott]

the blend functions in avx2 works like so:

 #define _mm256_blend_epi16(V1, V2, M) __extension__ ({       \
   (__m256i)__builtin_shufflevector((__v16hi)(__m256i)(V1),   \
                                    (__v16hi)(__m256i)(V2),   \
                                    (((M) & 0x01) ? 16 : 0),  \
                                    (((M) & 0x02) ? 17 : 1),  \
                                    (((M) & 0x04) ? 18 : 2),  \
                                    (((M) & 0x08) ? 19 : 3),  \
                                    (((M) & 0x10) ? 20 : 4),  \
                                    (((M) & 0x20) ? 21 : 5),  \
                                    (((M) & 0x40) ? 22 : 6),  \
                                    (((M) & 0x80) ? 23 : 7),  \
                                    (((M) & 0x01) ? 24 : 8),  \
                                    (((M) & 0x02) ? 25 : 9),  \
                                    (((M) & 0x04) ? 26 : 10), \
                                    (((M) & 0x08) ? 27 : 11), \
                                    (((M) & 0x10) ? 28 : 12), \
                                    (((M) & 0x20) ? 29 : 13), \
                                    (((M) & 0x40) ? 30 : 14), \
                                    (((M) & 0x80) ? 31 : 15)); })

any general tips on how to implement that such that LLVM will optimize it right?

something like:

pub fn _mm256_blend_epi16(a:i16x16,b:i16x16,imm8:i32) -> i16x16 {
    let imm8 = imm8 as u32;
    simd_shuffle16(a,b,
        [
            match imm8 & 0x01 {
                0 => 0,
                _ => 16
            },
            match imm8 & 0x02 {
                0 => 1,
                _ => 17
            },
            ...

        ])
}

[BurntSushi]

@jackmott I think it would be worth your time to carefully review x86/sse2.rs. There are some examples that define macros to get the right code gen. Ultimately, you want to make sure the right instruction is generated. The way I usually do it is stick a sample program in examples/whatever.rs, and then run RUSTFLAGS="--emit asm" cargo build --release --example whatever. Then look in target/release/examples for the asm output.

Do you want me to wait till the entire avx2 is done before doing a PR?

Up to you. Probably sending it in stages is a good idea. Please also write in a style that is consistent with the rest of the code.

I imagine you'll want a pub type __m256i = ::v256::i8x32;, yes. Whether we actually keep it or not, I'm not sure.

[jackmott]

the max functions in clang.s .h files are defined like so:

 static __inline__ __m256i __DEFAULT_FN_ATTRS
 _mm256_max_epi8(__m256i __a, __m256i __b)
 {
   return (__m256i)__builtin_ia32_pmaxsb256((__v32qi)__a, (__v32qi)__b);
 }

but don't appear in your extracted intrinsics gist list, and it seems like ones of this form should. Did it just get missed? Should I just infer the names then check that it is right with a test?

[BurntSushi]

Interesting. Maybe my regexes for extraction are bad? Can you find it in Intel's docs?

[jackmott]

the intel intrinsics reference? yeah they are all in there: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX2&text=max&expand=3298

[BurntSushi]

Probably just a bad regex then. :)

…

On May 28, 2017 6:20 PM, "Jack Mott" ***@***.***> wrote: the intel see reference? yeah they are all in there: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX2& text=max&expand=3298 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAb34s6aoGTpxzR6OBHWJpOJZIuM28jDks5r-fM9gaJpZM4NnigW> .

[jackmott]

let a = i8x32::splat(-1);        
let r = avx2::_mm256_movemask_epi8(a);

release build r = -1
debug build r = 65535

run into anything like that?

[BurntSushi]

I'd have to see the full code I think. There are still some details to iron out with #[target_feature] and the like that cause weird things to happen.

[jackmott]

Hmm, another intrinsic from the "Misc" section and a similar result:

#[link_name = "llvm.x86.avx2.mpsadbw"]
fn mpsadbw(a: u8x32, b: u8x32, imm8: i32) -> u16x16;

works fine in release, in debug I get this error when running cargo test:

LLVM ERROR: Cannot select: intrinsic %llvm.x86.avx2.mpsadbw

Its all up in my fork if you want to glance at it.

[BurntSushi]

@jackmott I don't know for sure, but my guess is that imm8 is an immediate value and therefore must be a constant at a compile time. In release mode, it probably works fine because it becomes a constant through various optimizations. But in debug mode, all bets are off. To fix this, you need to explicitly write out each call to the LLVM intrinsic with an explicit constant. You can see examples here https://github.com/jackmott/stdsimd/blob/master/src/x86/sse42.rs and here https://github.com/jackmott/stdsimd/blob/master/src/x86/sse2.rs#L282 --- Yes, they are a pain to write.

[BurntSushi]

I've started a guide for contributors: https://github.com/BurntSushi/stdsimd/blob/master/CONTRIBUTING.md

I'm going to close this issue for now, but I hope to improve the guide as we learn more!