Skip to content

Translate builtin_assume and unaligned SIMD intrinsics #1132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

thedataking
Copy link
Contributor

Unaligned vector types such as __m128_u or __256_u not not have any equivalents in Rust so we translate them to their aligned equivalents. This is unsound so we emit warning that the program may be mistranspiled. These fixes are required to transpile the zstd compressor on modern x86 hosts.

@thedataking thedataking added the bug Something isn't working label Sep 21, 2024
Unaligned vector types such as `__m128_u` or `__256_u` not not have
any equivalents in Rust so we translate them to their aligned equivalents.
This is unsound so we emit warning that the program may be mistranspiled.
Copy link
Contributor

@kkysen kkysen left a comment

Choose a reason for hiding this comment

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

How come overaligning isn't allowed in all cases? Padding differences?

Comment on lines +617 to +618
// TODO: provide proper implementation, this is just to get stuff building
"__builtin_assume" => Ok(self.convert_expr(ctx.used(), args[0])?),
Copy link
Contributor

Choose a reason for hiding this comment

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

When you do implement this, note that Rust (as of 1.81.0) now has core::hint::assert_unchecked, which should be the equivalent of __builtin_assume.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kkysen do you want to add support for __builtin_assume into a separate PR with a test?

It seems my PR is trying to do two things and only one is blocked on what rust provides, so that's messy.

WDYT about landing the rest of this PR? Should the warning reference the PR folkert opened?

Copy link
Contributor

Choose a reason for hiding this comment

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

do you want to add support for __builtin_assume into a separate PR with a test?

We're still stuck on the old nightly, so adding support for newer features like this is tricky. That said, we could merge #1227, which would use stable for c2rust-transpile and let us start targeting newer Rust versions for just the transpiler. #1227 didn't work before, but now that CI is on GitHub Actions, it works without much modifications, so it wouldn't be too much work to review and merge that. If we do that, I can add support for it.

Copy link
Contributor

@kkysen kkysen left a comment

Choose a reason for hiding this comment

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

There does seem to be some unaligned stuff in stdarch.
For example, _mm_storeu_si128.

Also, https://doc.rust-lang.org/std/arch/index.html?search=loadu.

Comment on lines +105 to +106
// Drop the `_u` suffix for unaligned SIMD types as they have
// no equivalents in Rust. Warn the user about possible probems.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use this for unaligned SIMD types?

Godbolt

use core::arch::x86_64::__m256;
use core::mem;

#[unsafe(no_mangle)]
pub fn aligned() -> usize {
    mem::align_of::<__m256>()
}

#[repr(packed)]
pub struct UnalignedM256(pub __m256);

#[unsafe(no_mangle)]
pub fn unaligned() -> usize {
    mem::align_of::<UnalignedM256>()
}

#[repr(packed)] lets you override the alignment and unalign a type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants