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

cranelift: add i64.{ishl,ushr,ashr} libcalls #1787

Merged
merged 1 commit into from
Jun 5, 2020

Conversation

whitequark
Copy link
Contributor

@whitequark whitequark commented May 29, 2020

These libcalls are useful for 32-bit platforms.

On x86_32 in particular, commit 4ec16fa added support for legalizing 64-bit shifts through SIMD operations. However, that legalization requires SIMD to be enabled and SSE 4.1 to be supported, which is not acceptable as a hard requirement.

(Actually, when implementing that commit I didn't yet realize that these shifts ought to be legalized via libcalls rather than expansions most of the time, but the expansions are just fine.)

With this commit it is finally possible to use cargo run --target i686-unknown-linux-gnu run foo.wasm without having to add --enable-simd.

@whitequark
Copy link
Contributor Author

cc @iximeow

@whitequark whitequark force-pushed the i64-shift-libcalls branch from c5901e3 to 1b20dab Compare May 29, 2020 15:58
@whitequark whitequark force-pushed the i64-shift-libcalls branch from 1b20dab to 09a78fd Compare May 29, 2020 16:00
@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:module labels May 29, 2020
@github-actions
Copy link

Subscribe to Label Action

cc @bnjbvr

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

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

  • bnjbvr: cranelift

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

Learn more.

@@ -1376,6 +1378,8 @@ fn convert_ushr(
let mut pos = FuncCursor::new(func).at_inst(inst);
pos.use_srcloc(inst);

let isa_flags = isa_settings::Flags::new(&isa.flags(), isa_settings::builder());
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a drive-by comment: I'm not too sure this will work. To get the ISA flags I had to add some extra machinery (see 849d71b)

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, you're right, it doesn't work. Which PR is that machinery added in?

Copy link
Contributor

@abrown abrown Jun 2, 2020

Choose a reason for hiding this comment

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

#1759, which should be ready to go; just needs a review. @bnjbvr, here's another use for the ISA-specific flag machinery I added.

Copy link
Contributor

Choose a reason for hiding this comment

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

(Oh, sorry, @whitequark, I see you already figured that out below!)

@whitequark
Copy link
Contributor Author

Looks like this PR depends on #1759.

@whitequark whitequark force-pushed the i64-shift-libcalls branch 2 times, most recently from 3dac9b0 to 5b491b8 Compare June 4, 2020 01:38
@whitequark
Copy link
Contributor Author

@abrown I rebased the PR on master. I think some checks are failing because of unrelated issues.

@abrown
Copy link
Contributor

abrown commented Jun 4, 2020

That's annoying; do you mind opening an issue for it? Looks like something to do with lightbeam and staticvec from this and this

@whitequark
Copy link
Contributor Author

That's annoying; do you mind opening an issue for it?

I'm confused, isn't master supposed to be always green?

@iximeow
Copy link
Contributor

iximeow commented Jun 4, 2020

Yes, but some tasks are nightly, with a recent nightly change invalidating what was otherwise fine. #1818 appears to fix this, try a rebase?

edit: lol, I see your most recent changes were also a rebase. "keep rebasing until it works" 😁

These libcalls are useful for 32-bit platforms.

On x86_32 in particular, commit 4ec16fa added support for legalizing
64-bit shifts through SIMD operations. However, that legalization
requires SIMD to be enabled and SSE 4.1 to be supported, which is not
acceptable as a hard requirement.
@whitequark whitequark force-pushed the i64-shift-libcalls branch from 5b491b8 to e3ece4b Compare June 4, 2020 21:57
@whitequark
Copy link
Contributor Author

Rebased

@whitequark
Copy link
Contributor Author

Looks like it's green now!

Copy link
Contributor

@abrown abrown left a comment

Choose a reason for hiding this comment

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

LGTM!

@abrown abrown merged commit bc55546 into bytecodealliance:master Jun 5, 2020
@whitequark whitequark deleted the i64-shift-libcalls branch June 6, 2020 02:31
@whitequark
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:module cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants