Jérôme Vouillon

> Speaking of which, once again I only see microbenchmark results: https://bench.ci.dev/ocsigen/js_of_ocaml/pull/1910/base/master/benchmark/Wasm_of_ocaml?worker=autumn&image=bench.Dockerfile Do you know why? The PR with the other benchmarks has not been merged yet.

### JS-API conversions It is not clear to me whether slices correspond to whole ArrayBuffers or just a portion of them. A coercion down to the underlying array buffer would...

> > We should probably support loading and storing [half-precision floating point numbers](https://github.com/WebAssembly/half-precision/blob/main/proposals/half-precision/Overview.md) as well > > I believe we would just need a `slice.load_v128` sort of instruction and that...

Indeed, an alternative would be to add some opcodes and/or primitives. But I'm not sure we want to make the bytecode interpreter and the runtime larger just for this.

> @vouillon, we currently can't distinguish makeblock from makearray at the bytecode level. Should we have a hint for that ? I'm not sure what we could do with that...

> We could use an hint to distinguish "int comparison" and "physical equality". Or we could use a different bytecode instruction. That could be useful, indeed. But it's a bit...

Here are the size of the largest sections in the ocaml bytecode executable. | Total | 24466262 | 100% | |-|-:|-:| | DBUG | 20802289 | 85.0% | | CODE...

There are also several occurrences of `effect`, which is now a keyword, in the code.

@hhugo Do you want to have a look?

@hhugo Can I just merge this PR? Or would it be better to wait after the next release?