Skip to content

Conversation

Parrot7483
Copy link
Collaborator

The changed AVX2 simd instructions in this PR are no longer unsafe. The Compiler gives a warning when using them in an unsafe block.

@Parrot7483 Parrot7483 requested a review from a team as a code owner August 20, 2025 12:48
@Parrot7483 Parrot7483 requested review from franziskuskiefer and Copilot and removed request for franziskuskiefer August 20, 2025 12:48
Copilot

This comment was marked as spam.

Copy link
Member

@franziskuskiefer franziskuskiefer left a comment

Choose a reason for hiding this comment

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

CI is failing

@Parrot7483 Parrot7483 marked this pull request as draft August 21, 2025 08:31
@Parrot7483
Copy link
Collaborator Author

Parrot7483 commented Aug 21, 2025

I miss some understanding on how to use compilation targets and configuration flags here.

For example the _mm256_sign_epi32 function is safe and is for the x86 or x86-64 target and feature avx2. Because the wrapping function uses #[inline(always)], one can not use #[target_feature(enable = "avx2")]

#[inline(always)]
#[hax_lib::fstar::before(r#"[@@ "opaque_to_smt"]"#)]
pub fn mm256_sign_epi32(a: Vec256, b: Vec256) -> Vec256 {
    _mm256_sign_epi32(a, b)
}

Function _mm256_setzero_si256 is for the same target but feature avx. It is also safe. Some other functions in avx2.rs might be for the older SSE2 instruction set extension. Some are also unsafe.

Is the correct way to use these SIMD functions for different features to put the correct #[cfg(target_feature = "...")] on each of them? This way one can keep using #[inline(always)]. The user of the library would then set the needed features.

The motivation for this being that safe functions are not wrapped in an unsafe block.

Maybe its also a good idea to separate them into different modules? A function for SSE2 being in avx2.rs might be confusing (at least for me).

Copy link
Member

@franziskuskiefer franziskuskiefer left a comment

Choose a reason for hiding this comment

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

You have to make sure to enable the target feature etc. But you also have to check if these are actually safe intrinsics for the stable Rust compiler.

@Parrot7483
Copy link
Collaborator Author

CPU intrinsics require an unsafe block because they are hardware-dependent. Running them on an unsupported CPU will crash the program. Only when using the HAX target we get a warning.

@Parrot7483 Parrot7483 marked this pull request as ready for review September 2, 2025 11:15
Copy link
Member

@franziskuskiefer franziskuskiefer left a comment

Choose a reason for hiding this comment

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

CI is failing

@franziskuskiefer franziskuskiefer added this pull request to the merge queue Sep 10, 2025
Merged via the queue into cryspen:main with commit 1576029 Sep 10, 2025
93 of 94 checks passed
@Parrot7483 Parrot7483 deleted the safe-simd branch September 11, 2025 08:27
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.

2 participants