Skip to content

[Test] s390x fix for objc_simd #22896

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

Conversation

levivic
Copy link
Contributor

@levivic levivic commented Feb 25, 2019

This is a fix for objc_simd test on s390x platform.

@compnerd
Copy link
Member

Okay, so S390x will stret the struct and SRoA the return and argument, seems reasonable.

@compnerd
Copy link
Member

@swift-ci please test and merge

@jrose-apple
Copy link
Contributor

Wait, no, not reasonable. Does s390x not have floating-point vector registers? A single-element Swift struct is always supposed to be treated as equivalent to its single member (unlike in C++).

@mundaym
Copy link
Contributor

mundaym commented Mar 4, 2019

Does s390x not have floating-point vector registers?

It does, but only on relatively recent machines (the z13 and z14, released in 2015 and 2017 respectively). If we change the default target to z13 then the vector ABI will be used and these tests pass as-is, but it means that Swift won't necessarily work out of the box on older machines.

@jrose-apple
Copy link
Contributor

It might make more sense to mark the test as XFAIL or UNSUPPORTED instead, then. @stephentyrone, any thoughts?

@stephentyrone
Copy link
Contributor

Yeah, this isn't clear to me, either. @rjmccall, what do you think these should look like at the SIL level?

@rjmccall
Copy link
Contributor

rjmccall commented Mar 5, 2019

I wouldn't expect anything to be different at the SIL level; the SIL/IR split is designed specifically so that CC things like this can be decided in IRGen. The only thing SIL does is ownership, abstraction patterns, and some simple expansion of tuples.

@rjmccall
Copy link
Contributor

rjmccall commented Mar 5, 2019

At the IR / ABI level, this seems reasonable enough as an ABI when you have no vectors available. If you have both a vector and a non-vector ABI, and you're interesting in supporting Swift on both of them, it would be nice to figure out a way to test both of them. Does the triple look different for the vector ABI, or is it determined by a secondary flag?

@mundaym
Copy link
Contributor

mundaym commented Mar 5, 2019

It's set by additional flags. If we set the target CPU to z13 then the vector ABI is automatically enabled. It can be further overridden using the "+vector" or "-vector" feature strings.

For the time being I think I'd be happy just supporting the non-vector version of the ABI. I see it as a performance optimization we can look into supporting later (there are still functional bugs on big endian platforms that need fixing). There aren't any Linux distributions (that I know of) that require z13 or above yet.

@stephentyrone
Copy link
Contributor

@swift-ci please test linux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants