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

Initial commit of SIMD support in wasmer. #542

Merged
merged 42 commits into from
Jul 24, 2019
Merged

Initial commit of SIMD support in wasmer. #542

merged 42 commits into from
Jul 24, 2019

Conversation

nlewycky
Copy link
Contributor

@nlewycky nlewycky commented Jul 9, 2019

Add SIMD support to wasmer, mostly unimplemented. There's an implementation in the LLVM backend, but the other backends are left unimplemented, and the wasmer C API also leaves V128 unimplemented.

Updates to LLVM 8.0.

@nlewycky nlewycky requested review from bjfish and losfair July 9, 2019 19:10
@nlewycky nlewycky changed the title First pass of SIMD support in wasmer. Initial commit of SIMD support in wasmer. Jul 9, 2019
Cargo.toml Outdated Show resolved Hide resolved
nlewycky and others added 10 commits July 10, 2019 14:23
…pec test.

These is one test failure remaining with V128 global variables.

* Fix trunc_sat. We need both the largest float that can be converted to an int
  and the largest int, they are not the same number.
* Implement calling of functions that take V128 by passing in two i64's.
* Improve support for V128 in spectests. Parse binary modules with the same
  features as the outer spectest. Fix compilation error involving Result in
  emitted .rs file. Handle V128 in more cases when producing .rs file. Parse
  the wast script with SIMD enabled.
* Adjust the WAVM spectest so that it parses with WABT and mostly passes with
  wasmer. Wabt is particular about ints not having decimal places and floats
  having decimal places. Wasmer does not support mutable globals or shared
  memory. Tests of shuffles are disabled. Some assert_invalid tests that wabt
  won't even parse are disabled.
Fixes last spec test failure from the WAVM SIMD spec test.
…ions.

Updates to wasmparser 0.34.0 and picks up a newer wasmerio/wabt.
I expect that the V128 changes have broken kernel-loader because I haven't taken care to ensure that the interface was updated the same way on both sides.
@syrusakbary
Copy link
Member

bors try

bors bot added a commit that referenced this pull request Jul 22, 2019
@bors
Copy link
Contributor

bors bot commented Jul 23, 2019

try

Build failed

@syrusakbary
Copy link
Member

bors try

bors bot added a commit that referenced this pull request Jul 23, 2019
@bors
Copy link
Contributor

bors bot commented Jul 23, 2019

try

Build succeeded

Operator::I16x8AddSaturateS => {
let (v1, v2) = state.pop2()?;
let (v1, v2) = (v1.into_int_value(), v2.into_int_value());
let v1 = builder.build_bitcast(v1, intrinsics.i16x8_ty, "");
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we name all the "" name parameters all over? I thought they may be outputted to ll?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Depends on LLVM. A debug LLVM preserves instruction names and a release LLVM discards them (the symbol table for instruction names can be rather slow!). Each opcode implementation should copy the state.var_name() to one of the LLVM instructions, and that's usually the same point where we go from naming the rust variable an input value to a result. I think I put names on any instruction that wasn't obvious.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bjfish I noticed that there were some opcodes which weren't using the state.var_name() at all. That should be fixed, please point it out if it isn't!

@nlewycky
Copy link
Contributor Author

bors try

bors bot added a commit that referenced this pull request Jul 24, 2019
cranelift-entity = { version = "0.31" }
cranelift-frontend = { package = "wasmer-clif-fork-frontend", version = "0.31" }
cranelift-wasm = { package = "wasmer-clif-fork-wasm", version = "0.31" }
cranelift-native = { git = "https://github.com/wasmerio/cranelift.git", rev = "060c5a8e3553540144ca08ca028972c57693fa6e" }
Copy link
Member

Choose a reason for hiding this comment

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

Can we update the versions of cranelift? (meaning: publishing our forks and use them here).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

src/bin/wasmer.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors bot commented Jul 24, 2019

try

Timed out

nlewycky and others added 4 commits July 24, 2019 13:48
This test is too large and therefore does not run by default, see
`fn is_fat_test` in spectests.rs.
This is needed in order for the resulting wasmer to be releasable.
@nlewycky
Copy link
Contributor Author

bors try

bors bot added a commit that referenced this pull request Jul 24, 2019
@bors
Copy link
Contributor

bors bot commented Jul 24, 2019

@syrusakbary syrusakbary merged commit e877e6d into master Jul 24, 2019
@bors bors bot deleted the simd branch July 24, 2019 22:35
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.

4 participants