Stream: git-wasmtime

Topic: wasmtime / PR #9987 winch: x64 atomic stores


view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 12:10):

MarinPostma opened PR #9987 from MarinPostma:winc-x64-atomic-store to bytecodealliance:main:

This PR implements x64 store operations:

https://github.com/bytecodealliance/wasmtime/issues/9734

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 12:10):

MarinPostma requested wasmtime-compiler-reviewers for a review on PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 12:10):

MarinPostma requested fitzgen for a review on PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 12:10):

MarinPostma requested wasmtime-core-reviewers for a review on PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 13:44):

github-actions[bot] commented on PR #9987:

Subscribe to Label Action

cc @saulecabrera

<details>
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 <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Jan 12 2025 at 16:00):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 14:15):

saulecabrera submitted PR review:

One thing that we might want to do as part of this change before proceeding further with the development of the rest of the instructions in the proposal, is to ensure that addresses are aligned for atomic loads/stores. See the alignment of the proposal.

To check for alignment, I'd recommend creating a new method in the CodeGen module (e.g., emit_check_alignment) and either calling it before calling emit_compute_heap_addr or enhancing emit_compute_heap_addr to check alignment internally if the load/store is atomic.

For reference, this is how alignment is handled in Cranelift.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 14:15):

saulecabrera created PR review comment:

                // To stay consistent with cranelift, we emit a normal store followed by a mfence,

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 15:22):

saulecabrera submitted PR review:

One thing that we might want to do as part of this change before proceeding further with the development of the rest of the instructions in the proposal, is to ensure that addresses are aligned for atomic loads/stores. See the alignment section of the proposal.

To check for alignment, I'd recommend creating a new method in the CodeGen module (e.g., emit_check_alignment) and either calling it before calling emit_compute_heap_addr or enhancing emit_compute_heap_addr to check alignment internally if the load/store is atomic.

For reference, this is how alignment is handled in Cranelift.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 18:09):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 19:53):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:07):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:09):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:20):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:21):

MarinPostma commented on PR #9987:

@saulecabrera I have added the align check

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:26):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:28):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 13 2025 at 20:31):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera created PR review comment:

Generally in the codegen module, we try to stick with the emit_* prefix, for consistency, could you update the name of this method?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera created PR review comment:

What do you think of either:

Heap address calculation is a very critical piece of the compiler, so I'd recommend against passing boolean params, to make it less error prone at call sites.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera created PR review comment:

I believe you could use a scratch register here? (scratch!(M))

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera created PR review comment:

One thing to note with using self.context.pop_to_reg is that this method needs to ensure that the value is pushed back to the value stack after all the checks are emitted, to ensure that emit_compute_heap_address is able to pop the address.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:16):

saulecabrera created PR review comment:

I'd recommend using self.context.pop_to_reg, which already handles all the cases for moving a value to a register; e.g., in this case if a the value is already a register, this code will emit a move, which could be avoided, and more importantly it'll reduce register pressure.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:54):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 14:58):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 15:21):

saulecabrera submitted PR review:

Looks good, thanks!

After the trailing comment is deleted, we can land this one.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 15:21):

saulecabrera created PR review comment:



view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 15:22):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 16:05):

MarinPostma commented on PR #9987:

@saulecabrera it's not working yet I had to move to a x86 machine to debug, I'll ping you when i fixed it

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:13):

MarinPostma submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:13):

MarinPostma created PR review comment:

I'm a bit worried about the risk of clobbering the a scratch register here. The register is used across multiple masm operation, and we do use scratch registers in masm often.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:23):

MarinPostma submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:23):

MarinPostma created PR review comment:

I've been playing around with that, but it turns out that we need to move the address to a register anyway, because we potentially need to add the offset to the addr, and we cannot do that with the addr as a dst, as we need the address intact for computing the heap address later on. The reason why we can't add with tmp as a dst, is because that will return a InvalidTwoArgumentForm.

In light of this, I think peeking and moving to tmp would save a mov in the case where we need to compute the offset. WDYT?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:31):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 17:44):

MarinPostma commented on PR #9987:

@saulecabrera, I have made the changes you requested, I also responded to your comments, let me know if you want me to make the changes I suggested in the comments instead.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 20:55):

saulecabrera submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 20:55):

saulecabrera created PR review comment:

Oh that's a good point yeah. My main concern with peek is that nothing is preventing any other method to accidentally pop the wrong value from the stack. However, since this pattern is local to this method, I don't think there's a huge risk, so yeah, let's try the peek approach. One comment to your original implementation, could you return an error instead of doing peek().unwrap()? We have CodeGenError::missing_values_in_stack for this kind of situation.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 12:44):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 13:04):

MarinPostma updated PR #9987.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 13:05):

MarinPostma commented on PR #9987:

@saulecabrera I made the final changes

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 13:41):

saulecabrera merged PR #9987.


Last updated: Jan 24 2025 at 00:11 UTC