winch: Initial integration with wasmtime#6119
Merged
saulecabrera merged 35 commits intoApr 5, 2023
Merged
Conversation
…epedencies in trampoline case
This is effectively an option to select the `Strategy` enumeration.
Hook this into the `TargetIsa::compile_function` hook as well. Currently this doesn't take into account `Tunables`, but that's left as a TODO for later.
Most of these are a WIP. It's missing trampolines for x64, but a basic one exists for aarch64. It's missing the handling of arguments that exist on the stack. It currently imports `cranelift_wasm::WasmFuncType` since it's what's passed to the `Compiler` trait. It's a bit awkward to use in the `winch_codegen` crate since it mostly operates on `wasmparser` types. I've had to hack in a conversion to get things working. Long term, I'm not sure it's wise to rely on this type but it seems like it's easier on the Cranelift side when creating the stub IR.
Member
|
The docs fix worked -- there was another failure regarding the order of crates in publish.rs: the relationship between |
1242b79 to
ef5f567
Compare
Member
|
Just one minor (hopefully final) change in f307452 to only run winch tests when in unix and x86_64, since there's no support for the fastcall calling convention yet. |
Contributor
Author
|
@saulecabrera thank you for getting this over the line! |
saulecabrera
added a commit
to saulecabrera/wasmtime
that referenced
this pull request
Apr 6, 2023
brendandburns
pushed a commit
to brendandburns/wasmtime
that referenced
this pull request
Apr 13, 2023
saulecabrera
added a commit
to saulecabrera/wasmtime
that referenced
this pull request
Apr 27, 2023
This change introduces handling of traps and relocations in Winch, which was left out in bytecodealliance#6119. In order to so, this change moves the `CompiledFunction` struct to the `wasmtime-cranelift-shared` crate, allowing Cranelift and Winch to operate on a single, shared representation, following some of the ideas discussed in bytecodealliance#5944. Even though Winch doesn't rely on all the fields of `CompiledFunction`, it eventually will. With the addition of relocations and traps it started to be more evident that even if we wanted to have different representations of a compiled function, they would end up being very similar. This change also consolidates where the `traps` and `relocations` of the `CompiledFunction` get created, by introducing a constructor that operates on a `MachBufferFinalized<Final>`, esentially encapsulating this process in a single place for both Winch and Cranelift.
saulecabrera
added a commit
to saulecabrera/wasmtime
that referenced
this pull request
Apr 27, 2023
This change introduces handling of traps and relocations in Winch, which was left out in bytecodealliance#6119. In order to so, this change moves the `CompiledFunction` struct to the `wasmtime-cranelift-shared` crate, allowing Cranelift and Winch to operate on a single, shared representation, following some of the ideas discussed in bytecodealliance#5944. Even though Winch doesn't rely on all the fields of `CompiledFunction`, it eventually will. With the addition of relocations and traps it started to be more evident that even if we wanted to have different representations of a compiled function, they would end up being very similar. This change also consolidates where the `traps` and `relocations` of the `CompiledFunction` get created, by introducing a constructor that operates on a `MachBufferFinalized<Final>`, esentially encapsulating this process in a single place for both Winch and Cranelift.
saulecabrera
added a commit
to saulecabrera/wasmtime
that referenced
this pull request
May 1, 2023
This change introduces handling of traps and relocations in Winch, which was left out in bytecodealliance#6119. In order to so, this change moves the `CompiledFunction` struct to the `wasmtime-cranelift-shared` crate, allowing Cranelift and Winch to operate on a single, shared representation, following some of the ideas discussed in bytecodealliance#5944. Even though Winch doesn't rely on all the fields of `CompiledFunction`, it eventually will. With the addition of relocations and traps it started to be more evident that even if we wanted to have different representations of a compiled function, they would end up being very similar. This change also consolidates where the `traps` and `relocations` of the `CompiledFunction` get created, by introducing a constructor that operates on a `MachBufferFinalized<Final>`, esentially encapsulating this process in a single place for both Winch and Cranelift.
saulecabrera
added a commit
that referenced
this pull request
May 2, 2023
* winch: Handle relocations and traps This change introduces handling of traps and relocations in Winch, which was left out in #6119. In order to so, this change moves the `CompiledFunction` struct to the `wasmtime-cranelift-shared` crate, allowing Cranelift and Winch to operate on a single, shared representation, following some of the ideas discussed in #5944. Even though Winch doesn't rely on all the fields of `CompiledFunction`, it eventually will. With the addition of relocations and traps it started to be more evident that even if we wanted to have different representations of a compiled function, they would end up being very similar. This change also consolidates where the `traps` and `relocations` of the `CompiledFunction` get created, by introducing a constructor that operates on a `MachBufferFinalized<Final>`, esentially encapsulating this process in a single place for both Winch and Cranelift. * Rework the shared `CompiledFunction` This commit reworks the shared `CompiledFunction` struct. The compiled function now contains the essential pieces to derive all the information to create the final object file and to derive the debug information for the function. This commit also decouples the dwarf emission process by introducing a `metadata` field in the `CompiledFunction` struct, which is used as the central structure for dwarf emission.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Another big thank you to @alexcrichton for helping out with this and wiring up some of the initial pieces!
What this includes:
wasmtime_environ::Compilertrait for Winch withwasmtimeConfigcompilerflag for the CLI, which will help us a lot in testing winch featureswasmtimeThings to note:
x86_64, as winch is iterating on it should fill out other architecturesTypedfunctions isn't included, these don't use trampolines which winch requires at this timeWasmtime*calling conventionsThe intention is to work on the above iteratively, but this first pass will make it much easier to test winch. We've been manually running it's output in a test environment, but moving that over to
wasmtimewould greatly simplify the process.