---
# System prepended metadata

title: Portable SIMD 2022-01-31 Meeting
tags: [Minutes, Portable SIMD]

---

# 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