Skip to content

Conversation

@eduardosm
Copy link
Contributor

No description provided.

@rustbot
Copy link
Collaborator

rustbot commented Jan 1, 2026

r? @sayantn

rustbot has assigned @sayantn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Comment on lines +138 to +153

$(#[$stability])+
impl crate::convert::From<crate::core_arch::simd::Simd<$elem_type, $len>> for $name {
#[inline(always)]
fn from(simd: crate::core_arch::simd::Simd<$elem_type, $len>) -> Self {
unsafe { crate::mem::transmute(simd) }
}
}

$(#[$stability])+
impl crate::convert::From<$name> for crate::core_arch::simd::Simd<$elem_type, $len> {
#[inline(always)]
fn from(simd: $name) -> Self {
unsafe { crate::mem::transmute(simd) }
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now easy to include thanks to the generic core_arch::simd::Simd type.

Comment on lines +83 to +89
// `#[derive(Clone)]` causes ICE "Projecting into SIMD type core_arch::simd::Simd is banned by MCP#838"
impl<T: SimdElement, const N: usize> Clone for Simd<T, N> {
#[inline]
fn clone(&self) -> Self {
*self
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why the ICE with #[derive(Clone)] did not happen with non-generic types.

Copy link
Contributor

@sayantn sayantn Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is normal, the derived Clone implementation tries to do the clone elementwise, projecting to the SIMD type in the process. The compiler explicitly rejects any SIMD type projection via an ICE.

The derived implementation looks like this

fn clone(&self) -> Self {
    Self(self.0.clone())
              ^ SIMD type field projection => ICE
}

edit: oh I just got the problem, why does the same ICE not occur for non-generic versions. I imagine this is due to optimizations, the compiler can eliminate the field projection for non-generic versions by doing a bitwise Copy, but for generic T, the compiler cannot ensure that Copy and Clone behave the same way. For example, the following code is perfectly valid

#[derive(Copy)]
struct Foo(u32);

impl Clone for Foo {
    fn clone(&self) -> Self {
        println!("Cloning");
        *self
    }
}

although I am just guessing.

@eduardosm eduardosm force-pushed the generic-simd-type-avoid-unsafe-tests branch 6 times, most recently from e08cdf5 to c6fa637 Compare January 1, 2026 22:46
Comment on lines -5552 to +5804
test_vcombine!(test_vcombine_f16 => vcombine_f16([3_f16, 4., 5., 6.],
[13_f16, 14., 15., 16.]));
#[cfg_attr(target_arch = "arm", simd_test(enable = "neon,fp16"))]
#[cfg_attr(not(target_arch = "arm"), simd_test(enable = "neon"))]
fn test_vcombine_f16() {
let a = f16x4::from_array([3_f16, 4., 5., 6.]);
let b = f16x4::from_array([13_f16, 14., 15., 16.]);
let e = f16x8::from_array([3_f16, 4., 5., 6., 13_f16, 14., 15., 16.]);
let c = f16x8::from(vcombine_f16(a.into(), b.into()));
assert_eq!(c, e);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer uses the test_vcombine due to the need of specifying "fp16" depending on ARM version.

@eduardosm eduardosm force-pushed the generic-simd-type-avoid-unsafe-tests branch 2 times, most recently from f51739a to ccfe133 Compare January 1, 2026 22:52
;;
armv7-*eabihf | thumbv7-*eabihf)
export RUSTFLAGS="${RUSTFLAGS} -Ctarget-feature=+neon"
export RUSTFLAGS="${RUSTFLAGS} -Ctarget-feature=+neon,+fp16"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since fp16 cannot be checked at runtime (at least is_arm_feature_detected does not support it), we enable it at compile time.

@eduardosm eduardosm force-pushed the generic-simd-type-avoid-unsafe-tests branch from ccfe133 to a290873 Compare January 2, 2026 21:08
@sayantn
Copy link
Contributor

sayantn commented Jan 5, 2026

The changes LGTM, although the simd_test changes seem a bit hacky, I guess we can live with it if it enables us to have a simpler life

@sayantn sayantn added this pull request to the merge queue Jan 5, 2026
Merged via the queue into rust-lang:main with commit 1b8539c Jan 5, 2026
75 checks passed
@eduardosm eduardosm deleted the generic-simd-type-avoid-unsafe-tests branch January 5, 2026 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants