-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Implement RFC 2574, "SIMD vectors in FFI" #86546
Conversation
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Sorry, I don't have time to review this right now. Reassigning arbitrarily to r? @oli-obk |
@varkor FWIW you could remove yourself from the review rotation if you'd like: https://github.com/rust-lang/highfive/blob/2d1fdf4d7321863060935c06fc7788c1081679e8/highfive/configs/rust-lang/rust.json#L8 |
@JohnTitor: I can find time to review smaller PRs (e.g. < 100 lines changed), which is why I haven't removed myself at the moment, but I have been auto-assigned quite a lot of larger ones recently; I may take your advice if I find it is too overwhelming :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's really addressed on this PR, should we?
since it already works on stable, we would have to make it a future incompat lint. Since it is already on stable, there's no hurry, it's not like this PR suddenly allows that, right? (if this PR allows that on stable, then yes, it needs to be fixed) So you can just open an issue for it.
/// Returns `Ok()` if the target-feature allows using the SIMD type on C FFI. | ||
/// Otherwise, returns `Err(Some())` if the target_feature needs to be enabled or | ||
/// or `Err(None)` if it's unsupported. | ||
fn simd_ffi_feature_check( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough about simd to properly review this function. @lqd can you help or ping others?
That said, the function body looks very fragile and easy to get accidentally wrong to me. Is there something declarative that we could parse and process here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, the function body looks very fragile and easy to get accidentally wrong to me. Is there something declarative that we could parse and process here?
I agree but I haven't come up with/know a better solution. @Amanieu Do you have any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The true source of these ABI constraints is in LLVM's handling of calling conventions. I don't think there is anything we can easily parse here.
My recommendation would be to directly refer to LLVM's source code for calling convention handling to determine which target features affect ABI.
In a way this is similar to what I had to do for asm!
in compiler/rustc_target/src/asm
which is similarly tied to LLVM implementation details for reserved registers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't LLVM be extended to provide APIs to query information about calling conventions instead of relying on its source code, which is also fragile. LLVM is huge database. Or maybe use tablegen to create rust files ...
// * on mips: 16 => msa, | ||
// * wasm: 16 => simd128 | ||
match simd_width { | ||
8 if feature.contains("mmx") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead of match:
if feature.contains("mmx") and simd_with == 8 {
return Ok(());
}
if feature.contains("see") and 8..=16.contains(simd_with) {
return Ok(());
}
...
if feature.contains("avx512") and 8..=64.contains(simd_width) {
return Ok(());
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not sure if it's much improvement, at least the current is readable enough to me. And I feel like that it makes it slightly harder to understand that what 8
, 16
, 32
, ... mean.
Yes, we can do it separately, I'm going to open a new issue. Thanks! EDIT: Opened #87438. |
☔ The latest upstream changes (presumably #87739) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from triage: |
@JohnTitor any updates on this? |
@JohnTitor @rustbot label: +S-inactive |
Re-submission of #59238, cc #63068
Remaining tasks:
[WIP] Implement RFC2574 for FFI declarations #59238 (comment)splitting to future-incompat: use of SIMD types aren't gated properly #87438I'm not sure if it's really addressed on this PR, should we?