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

Refiling "#[repr(simd)] struct(isize, isize) not allowed" #55078

Open
Centril opened this Issue Oct 15, 2018 · 9 comments

Comments

Projects
None yet
6 participants
@Centril
Contributor

Centril commented Oct 15, 2018

Refiling rust-lang/rfcs#2513 here.

This probably does not require an RFC (according to me and @nrc).
However, we'd like @BurntSushi and @alexcrichton to sign off on this.

cc @rust-lang/compiler
cc @gnzlbg

Repro (playground: https://play.rust-lang.org/?gist=efa6e5caf752ccca651014ae5009feb8&version=nightly&mode=debug&edition=2015):

#![feature(repr_simd)] 

#[repr(simd)] struct A(isize, isize); // ERROR

#[cfg(target_pointer_width = "64")]
type isize_ = i64;

#[cfg(target_pointer_width = "32")]
type isize_ = i32;

#[repr(simd)] struct B(isize_, isize_); // Q: Is this ok?

produces

error[E0077]: SIMD vector element type should be machine type
 --> src/main.rs:3:15
  |
3 | #[repr(simd)] struct A(isize, isize);
  |               ^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

I am wondering why aren't isize and usize allowed ? I currently work around this to implement simd vectors of pointers, but maybe that's broken for reason I don't understand?

@Centril

This comment has been minimized.

Contributor

Centril commented Oct 15, 2018

@rfcbot merge

@rfcbot

This comment has been minimized.

rfcbot commented Oct 15, 2018

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@Centril

This comment has been minimized.

Contributor

Centril commented Oct 15, 2018

@Centril

This comment has been minimized.

Contributor

Centril commented Oct 15, 2018

@rfcbot concern signoff-from-alex-and-andrew

@scottmcm

This comment has been minimized.

Member

scottmcm commented Oct 15, 2018

This is just adding another type to a feature that isn't on the path to stabilization, right?

@rfcbot reviewed

@Centril

This comment has been minimized.

Contributor

Centril commented Oct 15, 2018

@scottmcm yep :) (#27731 tracks repr(simd) in general)

@gnzlbg

This comment has been minimized.

Contributor

gnzlbg commented Oct 15, 2018

While #[repr(simd)] struct A(isize, isize); currently errors, #[repr(simd)] struct A<T>(T, T); type B = A<isize>; currently accidentally works on nightly.

The packed_simd crate has used this "bug" to export vectors of pointers and vectors of usize/isize/msize for a while and uses them in some of the examples (e.g. the examples/aobench tiled.rs algorithm).

Lifting the restriction makes something that's already possible and useful a bit easier to do. Also, the current plan is to never stabilize repr(simd), but to expose it through a std API. On stable, some of these are already exposed via std::arch (e.g. __m128), but none of them interact with isize/usize - so this does not interact with stable types at all.

Something like RFC2366 with support for packed SIMD vectors of pointers would need to be added to the language for this to land on stable.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Oct 15, 2018

The #[repr(simd)] feature currently (and I can't forsee at least) have any path to stabilization. In that sense I would not personally recommend working on this feature as it's basically just a building block for std::arch, which we must expose to the language somehow.

I suspect, however, that fixing this is probably a few lines of a patch. While I wouldn't at all prioritize this I wouldn't stop it if someone were motivated.

@varkor

This comment has been minimized.

Member

varkor commented Oct 15, 2018

I suspect, however, that fixing this is probably a few lines of a patch.

Namely, removing this line:

Int(ast::IntTy::Isize) | Uint(ast::UintTy::Usize) => false,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment