-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix s390x regressions #3330
Fix s390x regressions #3330
Conversation
Note: In addition to this PR, the endian fix in PR #3329 and the rsix build fix bytecodealliance/rustix#53 are required to make the CI tests fully pass again on s390x. |
Also: Using qemu 6.1 we should now be able to turn on upstream CI for the s390x platform. |
Subscribe to Label Actioncc @fitzgen
This issue or pull request has been labeled: "cranelift", "fuzzing"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
This pulls in the s390x fix needed by bytecodealliance#3330. Also a small `rsix` API update; `PollFdVec` has been removed in favor of just using `Vec<PollFd>`.
I opened #3331 to pull in the s390x fix in |
Thanks, @sunfishcode ! |
This pulls in the s390x fix needed by #3330. Also a small `rsix` API update; `PollFdVec` has been removed in favor of just using `Vec<PollFd>`.
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 think someone else will want to review the cranelift/codegen/src/isa/s390x/lower.rs
bits, but all the other bits look good to me.
@@ -201,6 +201,8 @@ fn ignore(testsuite: &str, testname: &str, strategy: &str) -> bool { | |||
("reference_types", _) if cfg!(feature = "old-x86-backend") => return true, | |||
// No simd support yet for s390x. | |||
("simd", _) if platform_is_s390x() => return true, | |||
// No memory64 support yet for s390x. | |||
("memory64", _) if platform_is_s390x() => return true, |
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.
How come memory64 isn't implemented on s390x? Does it lower to unimplemented clif things at the moment?
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.
Yes. This is all fixable, but I'd prefer to do that separately.
@@ -3621,6 +3624,7 @@ impl MachInstLabelUse for LabelUse { | |||
// This can address any valid CodeOffset. | |||
LabelUse::BranchRIL => 0x7fff_ffff, | |||
LabelUse::PCRel32 => 0x7fff_ffff, | |||
LabelUse::PCRel32Dbl => 0x7fff_ffff, |
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.
Given the shift, is the range actually one bit larger than what's specified 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.
The range is actually +/- 4GB, not +/-2 GB. But that apparently cannot be represented as CodeOffset anyway, so I simply accept all valid CodeOffsets 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.
Could this return 0xffff_ffff
as a placeholder? One day I think it'd be good to represent some code offsets in this area as a 64-bit integer, but that I think is a much bigger change.
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 tried that when adding BranchRIL (which has the same range) initially, and it caused failures (some kind of overflows in common code), so that's what I ended up with. I guess this could be revisited at some point, but then we should do it for all affected LabelUse types, not just PCRel32Dbl.
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.
Can the overflow be fixed with a saturating_add
or something like that somewhere? If not can the comment be updated that this should be 4GB but it's specified as 2GB for now?
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 would probably help, I'll give it a try. It's still better to do that in a separate PR I think.
- Add relocation handling needed after PR bytecodealliance#3275 - Fix incorrect handling of signed constants detected by PR bytecodealliance#3056 test - Fix LabelUse max pos/neg ranges; fix overflow in buffers.rs - Disable fuzzing tests that require pre-built v8 binaries - Disable cranelift test that depends on i128 - Temporarily disable memory64 tests
6d3a06e
to
1632d0e
Compare
@alexcrichton you were right, I just had to add a single Note that BranchRI max ranges were just completely wrong, but that type isn't currently used anywhere so it didn't matter. I've now fixed this and used precise max ranges for all types, only capped by a max of 0xffff_ffff due to the u32 type. |
Nah yeah that's what I would have expected for a |
Just want to mention that we have now upgraded to 6.1 in #3325 |
Thanks! @cfallin do you want to have a look at those? |
Excellent. Not sure exactly what we need to do to add a CI job for s390x, I haven't done much with GitHub actions before ... |
To add a CI job theoretically all that needs to be done is to copy/paste this block to add another entry below it, and then update the various values for s390x instead of aarch64. |
Thanks! I'll give it a try once the two PRs are merged. |
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.
Thanks! @cfallin do you want to have a look at those?
The label/MachBuffer changes look good to me!
So can this be merged now? This is now the final bit blocking successful builds on s390x ... |
This is now #3372 . I also had to disable the lightbeam tests (just like on aarch64). |
call
instructions between wasm functions #3275