fitzgen requested wasmtime-default-reviewers for a review on PR #9235.
fitzgen requested pchickey for a review on PR #9235.
fitzgen opened PR #9235 from fitzgen:pulley-compare-and-branch-64
to bytecodealliance:main
:
Need these for a follow up PR.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen requested alexcrichton for a review on PR #9235.
fitzgen updated PR #9235.
alexcrichton created PR review comment:
Not necessary for this PR, but I think it'd be good to avoid hardcoding 7 here eventually. This'll be hard to remember to update if we pack the
a/b
regs into a single byte for example (not that that's possible because there's 32-registers but similar-ish other encoding schemes might happen)
alexcrichton submitted PR review.
alexcrichton created PR review comment:
To bikeshed the names about, how about using the CLIF names which are all generally three letters? For example
ne
andeq
for the first two andslt
,sle
,ult
, andule
for the latter four.
fitzgen submitted PR review.
fitzgen created PR review comment:
These names match the 32-bit variants and the comparison-without-branching instructions. We can rename everything in a follow up, if you want, but I won't do it in this PR.
fitzgen submitted PR review.
fitzgen created PR review comment:
We can certainly define a
const OFFSET_OF_JUMP_IN_COND_BR_INST: usize = 7
constant and use that in place of this, but I don't know how we could get the macro to automatically keep the value up-to-date, so I'm not sure it would actually change things in practice. We'd still need to remember to update the constant definition when we bitpack stuff, for example.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Sounds good :+1:
alexcrichton submitted PR review.
alexcrichton created PR review comment:
I forget if this was already tried, but could relocation offsets be done such that a static offset here isn't needed? I forget if it's relative to the start or the end of the instruction but if we flip it then this constant here would go away and it's just the producer, Cranelift, that would get a bit more complicated right?
fitzgen updated PR #9235.
fitzgen has enabled auto merge for PR #9235.
fitzgen submitted PR review.
fitzgen created PR review comment:
Yeah, right now the jump is relative from the relative-offset's position, not the instruction's position. We could indeed make it relative to the instruction's position and then tweak emission in Cranelift a bit. That would be kind of nice, one less ALU op at runtime!
fitzgen requested wasmtime-compiler-reviewers for a review on PR #9235.
fitzgen updated PR #9235.
fitzgen requested cfallin for a review on PR #9235.
fitzgen has enabled auto merge for PR #9235.
fitzgen merged PR #9235.
Last updated: Nov 22 2024 at 16:03 UTC