eagr opened PR #9910 from eagr:pulley-vshuffle
to bytecodealliance:main
:
part of #9783
eagr requested fitzgen for a review on PR #9910.
eagr requested wasmtime-compiler-reviewers for a review on PR #9910.
eagr requested wasmtime-core-reviewers for a review on PR #9910.
eagr requested wasmtime-default-reviewers for a review on PR #9910.
eagr updated PR #9910.
github-actions[bot] commented on PR #9910:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "pulley"Thus the following users have been cc'd because of the following labels:
- fitzgen: pulley
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Instead of putting the
mask
into aVReg
could it be au128
immediate to thevshuffle
instruction itself? That should cut down on opcodes slightly and more closely matches the wasm semantics of the instruction.
eagr submitted PR review.
eagr created PR review comment:
could it be a
u128
immediate to thevshuffle
instruction itself?I remember not, but let me try again
eagr submitted PR review.
eagr created PR review comment:
vshuffle(VReg, VReg, VReg, u128)
would raise this errorthread '<unnamed>' panicked at cranelift/codegen/src/isa/pulley_shared/inst/emit.rs:109:9: encoded inst InstAndKind { inst: Raw { raw: VShuffle { dst: Writable { reg: VReg(p0v) }, src1: VReg(p0v), src2: VReg(p1v), mask: 41362427191743139026751447860679676176 } }, kind: PhantomData<cranelift_codegen::isa::pulley64::Pulley64> } longer than worst-case size: length: 22, Inst::worst_case_size() = 20
eagr submitted PR review.
eagr created PR review comment:
If it's ok, I guess I could raise the inst. size limit.
eagr updated PR #9910.
eagr updated PR #9910.
alexcrichton submitted PR review.
eagr updated PR #9910.
alexcrichton has enabled auto merge for PR #9910.
Do you happen to have something along the Pully pipeline that could use an extra pair of hands? I should probably leave these exercises for others. Btw, this is a wonderful setup for helping people learn about how Pulley works :)
alexcrichton merged PR #9910.
alexcrichton commented on PR #9910:
Sure yeah, whatever suits you best! Perhaps the next-lowest-hanging-fruit is performance optimizations which will involve running benchmarks and understanding the performance of Pulley and where hot-spots are. The main goal would be identifying macro-opcodes that can be added for lowering. The first one off the top of my head would be a macro opcode related to bounds checks to make memory accesses faster, but I haven't done performance profiling one way or another on that yet. (we also don't have many docs yet on how to do this so it's a choose-your-own-adventure at the moment, so not necessarily great as a first project)
Last updated: Jan 24 2025 at 00:11 UTC