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

Fix s390x regressions #3330

Merged
merged 1 commit into from
Sep 20, 2021
Merged

Conversation

uweigand
Copy link
Member

@uweigand
Copy link
Member Author

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.

@uweigand
Copy link
Member Author

Also: Using qemu 6.1 we should now be able to turn on upstream CI for the s390x platform.

@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator fuzzing Issues related to our fuzzing infrastructure labels Sep 11, 2021
@github-actions
Copy link

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "cranelift", "fuzzing"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

sunfishcode added a commit to sunfishcode/wasmtime that referenced this pull request Sep 11, 2021
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>`.
@sunfishcode
Copy link
Member

I opened #3331 to pull in the s390x fix in rsix.

@uweigand
Copy link
Member Author

I opened #3331 to pull in the s390x fix in rsix.

Thanks, @sunfishcode !

alexcrichton pushed a commit that referenced this pull request Sep 11, 2021
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>`.
Copy link
Member

@alexcrichton alexcrichton left a 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,
Copy link
Member

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?

Copy link
Member Author

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,
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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?

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 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
@uweigand
Copy link
Member Author

@alexcrichton you were right, I just had to add a single saturating_add. Given that this is just a one-line obvious fix to common code, I've now updated this PR after all. Let me know if you'd prefer me to take it out again.

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.

@github-actions github-actions bot added the cranelift:area:machinst Issues related to instruction selection and the new MachInst backend. label Sep 13, 2021
@alexcrichton
Copy link
Member

Nah yeah that's what I would have expected for a saturating_add and it looks good to me! I think someone will still want to look over the sconst changes to the s390x backend though.

@afonso360
Copy link
Contributor

Also: Using qemu 6.1 we should now be able to turn on upstream CI for the s390x platform.

Just want to mention that we have now upgraded to 6.1 in #3325

@uweigand
Copy link
Member Author

Nah yeah that's what I would have expected for a saturating_add and it looks good to me! I think someone will still want to look over the sconst changes to the s390x backend though.

Thanks! @cfallin do you want to have a look at those?

@uweigand
Copy link
Member Author

Also: Using qemu 6.1 we should now be able to turn on upstream CI for the s390x platform.

Just want to mention that we have now upgraded to 6.1 in #3325

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 ...

@alexcrichton
Copy link
Member

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.

@uweigand
Copy link
Member Author

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.

Copy link
Member

@cfallin cfallin left a 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!

@uweigand
Copy link
Member Author

So can this be merged now? This is now the final bit blocking successful builds on s390x ...

@alexcrichton alexcrichton merged commit 51131a3 into bytecodealliance:main Sep 20, 2021
@uweigand uweigand deleted the s390x-regressions branch September 20, 2021 14:25
@uweigand
Copy link
Member Author

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.

This is now #3372 . I also had to disable the lightbeam tests (just like on aarch64).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:machinst Issues related to instruction selection and the new MachInst backend. cranelift Issues related to the Cranelift code generator fuzzing Issues related to our fuzzing infrastructure
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants