# Portable SIMD 2022-01-31 Meeting

###### tags: `Portable SIMD` `Minutes`

[Last Meeting] | [This Meeting's Chat] | [Next Meeting]

<!-- [Last Meeting]: -->
[This Meeting's Chat]: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/Meeting.202022-01-31
<!-- [Next Meeting]: -->

## Agenda

- Latest sync + libm story update from Jubilee
- Notable additions: `std::simd::StdFloat`
- Was originally opened as https://github.com/rust-lang/rust/pull/91891
- Then work was added upstream at https://github.com/rust-lang/portable-simd/pull/219
- PR reopened as a sync PR: https://github.com/rust-lang/rust/pull/93146
- Now only waiting on ~~review~~ bors!
- Includes `Simd::cast` (which uses `simd_as`), thanks @calebzulawski!
- Re-adding "autosplats"
- Request to add for Shl/Shr in https://github.com/rust-lang/portable-simd/issues/225
- Inference failure issues:
- https://github.com/rust-lang/rust/issues/90904
- https://github.com/rust-lang/rust/issues/91872
- Inference failures seem to be with `ops::{Add, Mul, Sub, Div}`
- Only in ambiguous cases (e.g. use of `Default::default()` with `&T + &T` )
- Previously we have expressed a desire to maintain consistency, whatever impls we do
- Can we impl some things gradually and then pull back again if it turns out bad?
- [portable-simd#203] remains waiting on review.
- Anyone up for this?
- `simd::Float` + `Simd<T, N>` vs. `simd::Vector` + `SimdFloat<T,N>`
- Two paths diverged in a wood, etc.
- What measure portability?
- IEEE754 transcendental functions are not implemented to the last bit, yet are considered relatively portable nonetheless.
- It is likely some functions should be precise and others need not be quite as precise.
- `Simd::<T,N>::cast::<U>`, its future, and possible cleanup
- https://github.com/rust-lang/portable-simd/issues/233
- See: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/Simd.3A.3Acast.3A.3A.3CU.3E.28self.29
- Briefly: `fn cast` is a slightly awkward name, we've already discussed that.
- We can't use `fn as`, and `fn convert` isn't much clearer.
- PG-safe-transmute may or may not want `fn cast` for pure bitcasts
- We may or may not want to split float conversion methods from our bitcasts?
- Conciseness in naming / avoiding repeating `lanes_` everywhere.
- Language features like `as` exist precisely to make it possible and easy to convert.
- _(Your Text Here)_

## Resolutions

- Latest sync + libm story update from Jubilee
- waiting on bors
- Re-adding "autosplats"
- no incrementalism, ideally, easier to just keep things consistent
- "nah" on `&T $op &U`, drop
- "eh" on `T $op &U`, probably remove?
- Jubilee will take a shot at?
- [portable-simd#203] remains waiting on review.
- Jacob took a look at it
- `Simd::<T,N>::cast::<U>`, its future, and possible cleanup
- keep `fn cast` as is without splitting,
- defined as: it's not "a bitcast", it's an overloaded value conversion
- one of the conversions happens to be an isomorphism to ℤ/2ᴺℤ.
- therefore yes cleanup other functions
- `simd::Float` + `Simd<T, N>` vs. `simd::Vector` + `SimdFloat<T,N>`
- ???
- What measure portability
- ???
- Conciseness in naming / avoiding repeating `lanes_` everywhere.
- ???
- _(Your Text Here)_

[portable-simd#203]: https://github.com/rust-lang/portable-simd/pull/203