# Portable SIMD 2021-05-10 Meeting ###### tags: `Portable SIMD` `Minutes` [Last Meeting] | [This Meeting's Chat] | [Next Meeting] [Last Meeting]: https://hackmd.io/cAW2WJISSYWOW5a3qlipGQ [This Meeting's Chat]: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/Meeting.202021-05-10/near/238201030 [Next Meeting]: https://hackmd.io/tRDC_oOBRCeZrvK7ZMuXNQ ## Agenda 0. PR 117: https://github.com/rust-lang/stdsimd/pull/117 1. Consensus check on simd scatter/gather 2. Are there remaining concerns for nightly? Some possible ones: 2a. How do we test that we work on cranelift? 2b. We still need to add the rustc stability attributes 2c. Are there missing parts of our API? 3. libmvec??? 4. More concerns about X-to-bytes-to-X transmutations seem to be arising. ### Resolutions 0. merge 1. consensus is on a safe vector-of-indices scatter/gather model for now 2. 2a. we can figure out cranelift later. 2b. need to add rustc stability attributes and try to land in rustc as a subtree with compiler/libs help 2c. API seems mostly filled in? there's stuff we want to add but we can fill it in as we go. 3. ask wg-llvm for help w/ libmvec 4. add a `{to,from}_ne_bytes` transmute? much discussion: 5. coalesced around stability flag `core_simd_mod` for now 6. Jacob has started on a vector-math lib 7. someone please add a full problem statement of the libmvec thing somewhere? ## Next Time, on Dragonball Z... 0. schedule vector-of-pointers for review someday, somewhere :rainbow: 1. have we added `scatter`, `gather`, `{to,from}_ne_bytes`? 2. schedule cranelift review for someday 3. rustc stability attributes status? 4. are we ready to open a PR to land on nightly? 5. we need to draft the RFC? 6. what did wg-llvm say? libmvec problem statement: : vector math functions are not widely available and can't be used from core due to needing the external library, therefore we build a math lib for Rust that can be used everywhere and doesn't require external dependencies allowing it to be used in core so: SimdF32::sin() would then work everywhere SimdF32 works including webassembly, microcontrollers, etc also, it would be faster than just calling f32::sin a bunch of times the reason we go through all the hassle of getting llvm to generate calls to our library is then because it can instead generate the native sin instruction where supported, leaving it up to lllvm is by far the best option since it can do const-propagation, optimization, and is the best spot to make target-specific decisions this means we can't just use LLVM's existing features for a libmvec but require it to learn our new symbol names.