-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 atomic loads x64 #9970
Winch atomic loads x64 #9970
Conversation
winch/codegen/src/codegen/mod.rs
Outdated
ty: WasmValType, | ||
size: OperandSize, | ||
sextend: Option<ExtendKind>, | ||
atomic: bool, |
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.
Rather than a bool
, which can be error-prone, could you define a small enum WasmLoadKind { Regular, Atomic }
or similar and match on it in this function?
_size: OperandSize, | ||
_sextend: Option<ExtendKind>, | ||
) -> Result<()> { | ||
todo!() |
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.
Could you return a proper CodeGenError
instead of panicking? I'm in the process of enabling spec tests for aarch64, in general recoverable errors are preferred as it makes it easier to define when a particular proposal is not fully supported in a particular backend (like threads in aarch64
)
I believe we have CodeGenError::unimplemented_masm_instruction()
winch/codegen/src/isa/x64/masm.rs
Outdated
// The guarantees of the x86-64 memory model ensure that `SeqCst` | ||
// loads are equivalent to normal loads. |
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.
Given this comment and for the purposes of this pull request, I wonder if it's necessary to introduce a new method in the MacroAssembler. I'd prefer if possible, if we could instead extend the current load definition to take in a load_kind
argument, which categorizes if the load is atomic or not, similar to Chris' comment in https://github.com/bytecodealliance/wasmtime/pull/9970/files#r1909577300, that would also simplify the indirection happening in the CodeGen
module:
We could simplify to:
- Extending
emit_wasm_load
to take in a load kind - Performing the right dispatch directly from that method to the MacroAssembler, by passing the in-scope load kind.
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.
sure i'll do that
comments addressed |
I'll fix the test tommorow. |
Subscribe to Label Action
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config", "winch"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Label Messager: wasmtime:configIt looks like you are changing Wasmtime's configuration options. Make sure to
To modify this label's message, edit the To add new label messages or remove existing label messages, edit the |
I have enabled shared memory in winch, and updated the spec tests |
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.
Thanks!
this PR enable the thread feature for x64 in Winch, and implements atomic loads. This includes:
i32.atomic.load8_u
i32.atomic.load16_u
i32.atomic.load
i64.atomic.load8_u
i64.atomic.load16_u
i64.atomic.load32_u
i64.atomic.load
It also enabled shared memory for winch.
#9734
reopened from #9954 because the branch was wrong