Jamey Sharp
Jamey Sharp
> Is it possible to print a comment with the const value if one of the sides of the `iadd`/`isub`/etc.. is a const? That way we could recover some of...
> > Right. So [these rules in x64's lower.isle](https://github.com/bytecodealliance/wasmtime/blob/fbfceaec9821deec2d18587505f7efce2b0a42db/cranelift/codegen/src/isa/x64/lower.isle#L192-L221) can never match, yeah? > > Apparently so! We can go ahead and delete those; I suspect fuzz coverage, if we...
My draft fix for this is in #4939.
There's an older fork of wasmtime's binary-compatibly-builds action in https://github.com/fastly/js-compute-runtime/tree/main/.github/actions/binary-compatible-builds, which I made a number of improvements to a while back. It'd be nice if those converged again. I see...
I want to give this one more review pass after my first meeting this morning, but I think this is in great shape and I'm expecting to add my approval...
Perhaps optimizations like #4803 would do better if we keep bitwise CLIF operations on floats—we could express the optimization in the mid-end without introducing extra bitcast instructions. That said, looking...
It turns out that Wasmtime can actually generate SIMD bitwise ops on floating-point vectors, as in this example (from `tests/misc_testsuite/simd/issue_3327_bnot_lowering.wast` and #3327): ```wat (module (func $v128_not (export "v128_not") (result v128)...
I'm closing this issue as we seem to have reached consensus on keeping bitwise operations on floats.
CI failures are because today's release of Rust 1.63 reports a new warning. #4691 is merged fixing that, so please rebase and then hopefully CI will pass.
Also, I haven't tested the performance impact of this patch yet, just its correctness. We should try both the cranelift-fuzzgen input from #4931 and @adambratschikaye's example wasm program from #4923....