afonso360 opened PR #6954 from afonso360:riscv-fix-vmergevvm
to bytecodealliance:main
:
:wave: Hey,
This is the first fuzz bug for RISC-V from fuzzgen! It took 80 core-hours to find on QEMU.
The example code below produces the following instruction somewhere in the middle:
vmerge.vvm v0,v31,v3,v0.t #avl=2, #vtype=(e64, m1, ta, ma)
This is a masked operation that writes the results to the mask register. Apparently this is illegal in pretty much all opcodes except a handful (see § 5.3 Vector Masking).
We already have a mechanism to deal with instructions that can't write to one of their source operands, so the fix here is to also apply that to these masked instructions. I tried to look for a way to encode these constraints separately but gave up and decided that it isn't that big a deal to forbid all overlaps, even if we could just forbid the mask/dst overlap.
I've added a trait to organize overlapping information for opcodes, it Isn't strictly necessary but it gives me a nice centralized location to describe all the overlapping constraints (and how to merge them!).
afonso360 requested fitzgen for a review on PR #6954.
afonso360 requested wasmtime-compiler-reviewers for a review on PR #6954.
afonso360 edited PR #6954:
:wave: Hey,
This is the first fuzz bug for RISC-V from fuzzgen! It took 80 core-hours to find on QEMU.
The example code below produces the following instruction somewhere in the middle:
vmerge.vvm v0, v31, v3, v0.t #avl=2, #vtype=(e64, m1, ta, ma)
This is a masked operation that writes the results to the mask register. Apparently this is illegal in pretty much all opcodes except a handful (see § 5.3 Vector Masking).
We already have a mechanism to deal with instructions that can't write to one of their source operands, so the fix here is to also apply that to these masked instructions. I tried to look for a way to encode these constraints separately but gave up and decided that it isn't that big a deal to forbid all overlaps, even if we could just forbid the mask/dst overlap.
I've added a trait to organize overlapping information for opcodes, it Isn't strictly necessary but it gives me a nice centralized location to describe all the overlapping constraints (and how to merge them!).
afonso360 edited PR #6954:
:wave: Hey,
This is the first fuzz bug for RISC-V from fuzzgen! It took 80 core-hours to find on QEMU.
The example code below produces the following instruction somewhere in the middle:
vmerge.vvm v0, v31, v3, v0.t #avl=2, #vtype=(e64, m1, ta, ma)
This is a masked operation that writes the results to the mask register. Apparently this is illegal in pretty much all opcodes except for a handful (see § 5.3 Vector Masking).
We already have a mechanism to deal with instructions that can't write to one of their source operands, so the fix here is to also apply that to these masked instructions. I tried to look for a way to encode these constraints separately but gave up and decided that it isn't that big a deal to forbid all overlaps, even if we could just forbid the mask/dst overlap.
I've added a trait to organize overlapping information for opcodes, it Isn't strictly necessary but it gives me a nice centralized location to describe all the overlapping constraints (and how to merge them!).
afonso360 updated PR #6954.
afonso360 updated PR #6954.
afonso360 updated PR #6954.
alexcrichton submitted PR review.
alexcrichton merged PR #6954.
Last updated: Dec 23 2024 at 12:05 UTC