Rounding mode hacking discussion

[KloudKoder]

This is a placeholder issue for discussion of tasks required for phase 1 testing of new instructions with embedded rounding mode (RM).

[KloudKoder]

Ping @rossberg @sunfishcode @titzer @tlively <- You're all more experienced with WASM than I am. I'd like to hear your recommendations for how to hack this up. Can we maybe decide on some tasks to distribute? For starters, I'm willing to edit the instruction descriptions in the WASM manual if someone can point me to which doc I need to edit. Invite whoever else you see fit.

[tlively]

The first step would be to create a new proposals/rounding-mode-control/Overview.md document and link to it from the top-level README.md. It would be good to check out the overview docs on some of the other proposals to get an idea for the kind of content that usually goes in there, but that would be the best place to list the details for the newly proposed instructions at this stage.

[rossberg]

Here are pointers to relevant documentation:

• See the howto for setting up a proposal repo properly.

• As @tlively said, you can peek at other proposals for inspiration how to write the initial overview doc.

• See the phases doc for how to advance a proposal forward and what the deliverables are for each phase.

Can we maybe decide on some tasks to distribute? For starters, I'm willing to edit the instruction descriptions

Just to set expectations: by default, the champion of a proposal is the main person responsible for most of the work that is described in the above docs. Of course, they can try to get other interested people on board to distribute that work. But everybody is very busy, so don't expect too much. Often the only help champions get is that other folks do code reviews. Either way, better plan to spend substantial amounts of time on it. ;)

The only work for which you usually have to depend on others is the implementation in production engines required in a later phase. For that, you basically need engine vendors prioritising the proposal high enough that they start working on incorporating it. That can take considerable time, but if the proposal is in a good shape then it will happen.

[KloudKoder]

@tlively Thanks, got it. I'll post an update here when I have an overview markdown to share. I'll try to follow the format of the existing proposals you linked.

@rossberg Thanks for the links, so at least I have a "map" now. I've literally never compiled anything to WASM so yeah, this could be a long learning curve. So long, in fact, that I think it would be preferable to take up Conrad Watt's offer to hack up a bunch of switch statements for the sake of quickly turning every float arithmetic instruction into an RM-sensitive one.

You there, @conrad-watt ? If so, what do you suggest? Have I misunderstood what you were proposing?

[conrad-watt]

To be explicit, I was imagining supporting a source/IR-level "ambient mode + op" set of intrinsics by lowering to a Wasm-level

global $rounding_mode i32

function $fesetround ...
  set $rounding_mode

function $add_float
  if $rounding_mode = 1
    then add_ceil
  elif $rounding_mode = 2
    then add_floor
  ...

In this example (with apologies for the suspicious pseudo-code), source-level fesetround + add_float intrinsics are compiled to Wasm by effectively software-emulating the fpenv.

This was meant to be a relatively low-effort suggestion to get programs with such intrinsics compiling to Wasm if we went with instruction-level rounding modes as currently proposed. However, this isn't something I have the bandwidth or expertise to engineer myself.

[KloudKoder]

@conrad-watt Thanks, I understand. I think it's a good hack for a proof-of-concept. I could just copy the rounding mode from the opcode byte directly into your $rounding_mode.

But in order to do that... is there any particular assembler which any of you would recommend for use with WASM, mainly for this sort of low-level test hacking? It would be easier if I could just bypass the usual runtime bloat of C++, Rust, etc. Specifically, I'm looking for the ability to write individual WASM instructions (and, ultimately, modify the assembler in order to encode the proposed new ones so that a hacked version of WASM itself could execute them). An internet search basically just pointed me back to WASM.

[tlively]

A couple options would be to add the new instructions to WABT to use its wat2wasm tool or Binaryen to use its wasm-as tool. You could also implement the instructions in the reference interpreter itself, right here in this repo. Here's a PR adding instructions to Binaryen that you could look at to get a feel for what changes would be necessary in that code base: WebAssembly/binaryen#5214.

[KloudKoder]

@tlively Thanks! Seems like I ought to be able to cobble something together from all that.

[conrad-watt]

Just one more thought - to reduce your exposure to the Wasm-specific parts of the compilation it may make sense to directly expose the hypothetical "per-instruction rounding" Wasm instructions as intrinsics, and then do the strategy sketched above (#2 (comment)) as more of a source-to-source or generic IR-to-IR translation on code written in the fesetround style.

[KloudKoder]

@conrad-watt Thanks, I think I see what you mean. So basically connect the source code to the compiled code with macro middleware that implements a "set rounding mode" instruction. That makes sense.

[conrad-watt]

Of course, if you know of any code that is already directly written in terms of "per-instruction rounding mode" intrinsics, that would be even better!

[KloudKoder]

Progress update... Finally got started on this in earnest. I've decided to go the WABT route, hoping to implement RMs in the interpreter. At present I'm still trying to figure out where the relevant instructions are actually implemented. For example, if I search for "f64.sqrt", I see some tests for it along with some SIMD implementation stuff, but I don't see the basic floating-point implementation either as an interpretation function (which literally executes it) or a compiler function (which injects machine code into an output stream). Surely it's here somewhere but it's probably obscured by renaming. Same goes for other instructions impacted by RM. If I can't make progress on this soon, I guess I'll give up and try my luck with Binaryen.

[dschuff]

For adding new instructions to the interpreter, there are a few layers to go through. For instructions like unary operators, the dispatching is done in https://github.com/WebAssembly/wabt/blob/main/src/interp/interp.cc#L1141 with some of the implementations bottoming out in the corresponding header (https://github.com/WebAssembly/wabt/blob/b335131b5983c055bae8e7d0e6724ea556aa843d/include/wabt/interp/interp-math.h#L250) From the top end, you'd also need to add opcodes (https://github.com/WebAssembly/wabt/blob/main/include/wabt/opcode.h) and fill in some layers in between. I'd suggest posting an issue in the WABT repo and you can get some more specific help.

[KloudKoder]

@dschuff Thanks! Based on those filenames you provided, I was able to track down the problem: my search script was silently truncating the result list so they never showed up. Problem between keyboard and chair. So, yeah, I think I have enough to chew on now, and will inquire with WABT folks as needed.