-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
winch: Implement new trampolines #6358
winch: Implement new trampolines #6358
Conversation
Subscribe to Label Action
This issue or pull request has been labeled: "winch"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
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.
Nice!
Random thought about pinned registers -- while this isn't a problem for winch yet the final set of trampolines are the libcall trampolines which enter the runtime for instructions like |
f3cf780
to
becb391
Compare
@alexcrichton I've addressed all of your comments; I think this is ready for another pass. I've opted to leave the translation between Regarding your other comments, I've introduced |
I'm not exactly sure why the MIRI check is failing. |
e0c7b64
to
5677405
Compare
I realized that all the other tests are ignoring miri, so I applied the same attribute to Winch's tests. |
5677405
to
f0e2850
Compare
This change is a follow-up to bytecodealliance#6262, in which the new trampolines, described [here](https://github.com/bytecodealliance/rfcs/blob/main/accepted/tail-calls.md#new-trampolines-and-vmcallercheckedanyfunc-changes), were introduced to Wasmtime. This change, focuses on the `array-to-wasm`, `native-to-wasm` and `wasm-to-native` trampolines to restore Winch's working state prior to the introduction of the new trampolines. It's worth noting that the new approach for trampolines make it easier to support the `TypedFunc` API in Winch. Prior to the introduction of the new trampolines, it was not obvious how to approach it. This change also introduces a pinned register that will hold the `VMContext` pointer, which is loaded in the `*-to-wasm` trampolines; the `VMContext` register is a pre-requisite to this change to support the `wasm-to-native` trampolines. Lastly, with the introduction of the `VMContext` register and the `wasm-to-native` trampolines, this change also introduces support for calling function imports, which is a variation of the already existing calls to locally defined functions. The other notable piece of this change aside from the trampolines is `winch-codegen`'s dependency on `wasmtime-environ`. Winch is so closely tied to the concepts exposed by the wasmtime crates that it makes sense to tie them together, even though the separation provides some advantages like easier testing in some cases, in the long run, there's probably going to be less need to test Winch in isolation and rather we'd rely more on integration style tests which require all of Wasmtime pieces anyway (fuzzing, spec tests, etc). This change doesn't update the existing implmenetation of `winch_codegen::FuncEnv`, but the intention is to update that part after this change. prtest:full
f0e2850
to
e9fecc4
Compare
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.
Looks good to me! @cfallin may want to also take a look at some of the assembly bits too though?
0fc38d5
to
0eff833
Compare
Agreed; @cfallin, re-added you as a reviewer, let me know if you have any thoughts! |
Yep, I'll take a look 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.
Overall this looks very reasonable -- no objections (and thanks Alex for doing the detailed review here)!
This change is a follow-up to bytecodealliance#6358 This change implements the necessary stores of SP, FP and return address for fast stack walking.
* winch(trampolines): Save SP, FP and return address This change is a follow-up to #6358 This change implements the necessary stores of SP, FP and return address for fast stack walking. * Ignore backtrace test on Windows Temporarily ignoring Winch's trap test on Windows while support for unwind information is added.
This commit is a small cleanup to drop the usage of the `FuncEnv` trait. In bytecodealliance#6358, we agreed on making `winch-codegen` directly depend on `wasmtime-environ`. Introducing a direct relatioship between `winch-codegen` and `wasmtime-environ` means that the `FuncEnv` trait is no longer serving its original purpose, and we can drop the usage of the trait and use the types exposed from `winch-codegen` directly instead. Even though this change drops the `FuncEnv` trait, it still keeps a `FuncEnv` struct, which is used during code generation.
This commit is a small cleanup to drop the usage of the `FuncEnv` trait. In bytecodealliance#6358, we agreed on making `winch-codegen` directly depend on `wasmtime-environ`. Introducing a direct relatioship between `winch-codegen` and `wasmtime-environ` means that the `FuncEnv` trait is no longer serving its original purpose, and we can drop the usage of the trait and use the types exposed from `winch-codegen` directly instead. Even though this change drops the `FuncEnv` trait, it still keeps a `FuncEnv` struct, which is used during code generation.
This commit is a small cleanup to drop the usage of the `FuncEnv` trait. In bytecodealliance#6358, we agreed on making `winch-codegen` directly depend on `wasmtime-environ`. Introducing a direct relatioship between `winch-codegen` and `wasmtime-environ` means that the `FuncEnv` trait is no longer serving its original purpose, and we can drop the usage of the trait and use the types exposed from `winch-codegen` directly instead. Even though this change drops the `FuncEnv` trait, it still keeps a `FuncEnv` struct, which is used during code generation.
This commit is a small cleanup to drop the usage of the `FuncEnv` trait. In #6358, we agreed on making `winch-codegen` directly depend on `wasmtime-environ`. Introducing a direct relatioship between `winch-codegen` and `wasmtime-environ` means that the `FuncEnv` trait is no longer serving its original purpose, and we can drop the usage of the trait and use the types exposed from `winch-codegen` directly instead. Even though this change drops the `FuncEnv` trait, it still keeps a `FuncEnv` struct, which is used during code generation.
…6400) This change is a follow-up to bytecodealliance#6358 This change implements the necessary stores of SP, FP and return address for fast stack walking.
This change is a follow-up to
#6262, in which the new trampolines, described here, were introduced to Wasmtime.
This change, focuses on the
array-to-wasm
,native-to-wasm
andwasm-to-native
trampolines to restore Winch's working state prior to the introduction of the new trampolines. It's worth noting that the new approach for trampolines make it easier to support theTypedFunc
API in Winch. Prior to the introduction of the new trampolines, it was not obvious how to approach it.This change also introduces a pinned register that will hold the
VMContext
pointer, which is loaded in the*-to-wasm
trampolines; theVMContext
register is a pre-requisite to this change to support thewasm-to-native
trampolines.Lastly, with the introduction of the
VMContext
register and thewasm-to-native
trampolines, this change also introduces support for calling function imports, which is a variation of the already existing calls to locally defined functions.The other notable piece of this change aside from the trampolines is
winch-codegen
's dependency onwasmtime-environ
. Winch is so closely tied to the concepts exposed by the wasmtime crates that it makes sense to tie them together, even though the separation provides some advantages like easier testing in some cases, in the long run, there's probably going to be less need to test Winch in isolation and rather we'd rely more on integration style tests which require all of Wasmtimepieces anyway (fuzzing, spec tests, etc).
This change doesn't update the existing implmenetation of
winch_codegen::FuncEnv
, but the intention is to update that part after this change.