Skip to content
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

Closed
wants to merge 12 commits into from

Conversation

JohnTitor
Copy link
Member

@JohnTitor JohnTitor commented Jun 22, 2021

Re-submission of #59238, cc #63068

Remaining tasks:

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 22, 2021
@rust-log-analyzer

This comment has been minimized.

@varkor
Copy link
Member

varkor commented Jun 30, 2021

Sorry, I don't have time to review this right now. Reassigning arbitrarily to r? @oli-obk

@rust-highfive rust-highfive assigned oli-obk and unassigned varkor Jun 30, 2021
@JohnTitor
Copy link
Member Author

@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
(I've heard you're going to focus on the PhD studies, I wish best of luck with it :))

@varkor
Copy link
Member

varkor commented Jul 1, 2021

@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 :)

Copy link
Contributor

@oli-obk oli-obk left a 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(
Copy link
Contributor

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?

Copy link
Member

Choose a reason for hiding this comment

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

I can help ... by asking the 2 greats @Amanieu and @nagisa for help ^^

Copy link
Member Author

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?

Copy link
Member

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.

Copy link

@tschuett tschuett Jul 25, 2021

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")
Copy link

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(());
}

Copy link
Member Author

@JohnTitor JohnTitor Jul 24, 2021

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.

compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
@crlf0710 crlf0710 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2021
@JohnTitor
Copy link
Member Author

JohnTitor commented Jul 24, 2021

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.

Yes, we can do it separately, I'm going to open a new issue. Thanks!

EDIT: Opened #87438.

@bors
Copy link
Contributor

bors commented Aug 24, 2021

☔ The latest upstream changes (presumably #87739) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 12, 2021
@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 27, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 14, 2021
@JohnCSimon
Copy link
Member

Ping from triage:
@JohnTitor - can you please post your status on this PR? You have a merge conflict. Is this abandoned?

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 5, 2021
@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 6, 2022
@Dylan-DPC
Copy link
Member

@JohnTitor any updates on this?

@JohnCSimon
Copy link
Member

@JohnTitor
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this. Thanks for your contribution.

@rustbot label: +S-inactive

@JohnCSimon JohnCSimon closed this Mar 20, 2022
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Mar 20, 2022
@JohnTitor JohnTitor deleted the simd-ffi branch June 25, 2023 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.