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

Stop projecting into SIMD types in ui/simd/ tests #138036

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

Conversation

scottmcm
Copy link
Member

@scottmcm scottmcm commented Mar 5, 2025

Part of MCP838

This intentionally leaves projections in two places, as a double-check that what stdarch is still using (for now) continues to work

But the things that aren't testing that change to not using .0 on the repr(simd) type.

@rustbot
Copy link
Collaborator

rustbot commented Mar 5, 2025

r? @cjgillot

rustbot has assigned @cjgillot.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 5, 2025
@compiler-errors
Copy link
Member

Are u planning on making field access on repr(simd) in HIR a hard error as the next step or what?

@scottmcm
Copy link
Member Author

scottmcm commented Mar 5, 2025

@compiler-errors Well, I need to get a stdarch PR in before I can truly ban anything.

Locally I've got it banned in the MIR validator (as the fastest way to get an ugly error about it) but a HIR one would certainly be better.

EDIT: stdarch PR rust-lang/stdarch#1740

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

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

There's nothing wrong w these changes necessarily, but I do feel several tests took a slightly different migration strategy, and they could be made a bit more consistent for better readability.

Comment on lines +20 to +22
let a = $a;
let b = $b;
assert_eq!(a.to_array(), b.to_array());
Copy link
Member

@compiler-errors compiler-errors Mar 5, 2025

Choose a reason for hiding this comment

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

is this necessary? can we not just use $a.to_array()? Also maybe rename this to assert_eq_simd! like the tests below?

fn to_array(self) -> [i32; N] { unsafe { std::intrinsics::transmute_unchecked(self) } }
}

macro_rules! all_eq {
Copy link
Member

Choose a reason for hiding this comment

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

Same as above.

Comment on lines +18 to +21
for (u, (uu32, ui64)) in u
.to_array()
.iter()
.zip(uu32.to_array().iter().zip(ui64.to_array().iter()))
Copy link
Member

Choose a reason for hiding this comment

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

nitpick but u.to_array().into_iter().zip(uu32.to_array()).zip(ui64.to_array()) is a bit simplier 🤔

Comment on lines +49 to +50
let [b, a] = [$b, $a];
let [b, a] = [b.to_array(), a.to_array()];
Copy link
Member

Choose a reason for hiding this comment

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

this is pretty awkward lol, is this really necessary for the test?

Copy link
Member

Choose a reason for hiding this comment

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

let a = $a.to_array();
let b = $b.to_array();

Or else just replace this with the same assert_eq_simd macro as everything else.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, this one was weird. As the comment says, it was already doing weird things with type inference. I'll see if I can simplify it...

@@ -27,7 +31,7 @@ fn main() {

let r_strided = simd_gather(default, pointers, mask);

assert_eq!(r_strided, s_strided);
assert_eq!(r_strided.to_array(), s_strided.to_array());
Copy link
Member

Choose a reason for hiding this comment

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

macro-wise, should we replace this with assert_eq_simd! rather than calling to_array everywhere?


macro_rules! all_eq {
($a: expr, $b: expr) => {{
let a = $a;
Copy link
Member

Choose a reason for hiding this comment

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

Ping

assert!(const_ptrs.0 == [ptr as *const u8, core::ptr::null()]);
assert!(exposed_addr.0 == [ptr as usize, 0]);
assert!(with_exposed_provenance.0 == ptrs.0);
assert!(const_ptrs.to_array() == [ptr as *const u8, core::ptr::null()]);
Copy link
Member

Choose a reason for hiding this comment

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

make this more unified w the rest of the tests

@compiler-errors
Copy link
Member

Locally I've got it banned in the MIR validator (as the fastest way to get an ugly error about it) but a HIR one would certainly be better.

Oh, yeah, MIR validation is probably fine too. It can be an ICE; it doesn't need to be a good diagnostic.

@scottmcm scottmcm 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 Mar 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

4 participants