There is also this guide https://v8.dev/docs/webassembly-opcode on how to add a new WebAssembly instruction, basically what Jakob wrote :) with some diffs and (outdated line numbers). It is slightly outdated in that it doesn't mention turboshaft (was written before it).
On Tue, May 21, 2024 at 9:00 PM Jakob Kummerow <jkumme...@chromium.org> wrote: > Hi, > > We (V8 team) don't have much interest in this feature at this time, mostly > because of the relative lack of common use cases. That means you shouldn't > expect to get much help from us (personally I'm not planning to do more > than write this email), but of course that doesn't stop you from building a > V8-based prototype yourself. You can, at least at first, simply do that > locally, i.e. without upstreaming it right away -- that might follow later, > when your code is in good shape and the proposal is advancing. > > To get a V8 checkout, see https://v8.dev/docs/source-code. (In short: get > depot_tools and then do fetch v8. I think everything else isn't necessary > at first. In particular, git cl upload is a convenient way to share your > work with others, but not required for local development.) > See other docs on v8.dev/docs for helpful tips on how to build, how to > set up IDEs, debuggers, etc. > Keep in mind that various types of builds all exist for a reason: > x64.release is for performance measurements, x64.optdebug is for running > tests with DCHECK coverage, x64.debug is for interactive debugging. > Substitute arm64 for x64 if that matches your hardware. > > You can add new Wasm instructions in src/wasm/wasm-opcodes.h. > They'll be decoded by code in src/wasm/function-body-decoder-impl.h. > The baseline compiler is implemented in > src/wasm/baseline/liftoff-compiler.cc, and the platform-specific parts in > liftoff-assembler*. Tip: focus on one platform first, then do the others > once that's working (or even later, only when you approach upstreaming). > Liftoff is the easier compiler to work with; for a first stab at getting > things working it's also the optional one: you can simply make it bail out > for the new operations. By virtue of being the baseline compiler, it's not > suitable for performance measurements. > The most time-consuming part will be integration with the optimizing > compiler. The entry point is in src/wasm/turboshaft-graph-interface.cc. > You may then have to update various places along the compilation pipeline > in src/compiler/turboshaft/* and src/compiler/backend/*. I don't have a > specific suggestion how to design the changes there -- perhaps add an > option to FloatBinopOp, and check if that needs special handling in > various transformations? Tracing how various bits of code fit together can > be a bit difficult due to the amount of templatization; I'd recommend to > use plaintext search in addition to semantic indexing; in particular grep > for "ReduceFoo" to find out what happens to "Foo" operations in various > stages. You can run d8 with --print-wasm-code to see if the generated > code matches your expectations; for debugging the compilation process it's > often useful to use --trace-turbo and open the resulting .json file with > our visualization tool Turbolizer > <https://v8.github.io/tools/head/turbolizer/index.html>. > You can ignore the "Turbofan" (as opposed to "Turboshaft") pipeline, as > that's about to be turned off. > For tests, you can add the new instructions to > test/mjsunit/wasm/wasm-module-builder.js, and then follow the many > examples in test/mjsunit/wasm/* for defining and executing Wasm modules > that use them. > > I'm aware that this isn't a very detailed plan, and your learning curve > will be steep. Good luck! > > --Jakob > > > On Mon, May 20, 2024 at 6:32 PM Kloud Koder <kloudkoder...@gmail.com> > wrote: > >> To whom it may concern: >> >> As some of you may be aware, Paul Dennis (whirlicote on Github) and I >> (KloudKoder) are trying to enable floating-point (FP) instructions with >> explicit rounding modes (RMs) in WebAssembly. The motivation is to >> trivialize analog security via interval arithmetic (which provides >> guarantees about where a given real number resides). As part of our work >> with the WebAssembly Community Group, we were tasked with producing a >> prototype implementation in V8. The required changes are conceptually >> simple and at this point we're just looking for implementation guidance. >> For that matter, if you feel strongly one way or the other about this, then >> we invite your feedback. >> >> Several months ago, Paul submitted a prototype design for their reference >> interpreter for some new FP instructions which include an explicit rounding >> mode. For example, instead of FP division, one could now have: >> >> divide_floor >> divide_ceil >> divide_chop >> divide_nearest_even (already existing as simply "divide") >> >> in the usual 32-bit and 64-bit widths. >> >> There are also new rounding instructions which convert between floats and >> ints, and promote or demote between precisions, all with an explicit RM. >> We've also added support for the extraction of arithmetic (trinary) or >> logical (binary) signs. >> >> For my part, I provided him with thousands of corner cases for testing >> against actual Intel FPU (IEEE754) hardware. There's full coverage of all >> unique instruction behavior, with some esoteric exceptions involving NaNs >> that are already the subject of relevant canonicalization efforts, absent >> any of this. >> >> While there are tens of new instructions, the implementation is actually >> quite repetitive, basically consisting of hardware RM switches before and >> after an FP operation. >> >> But if that's still too overwhelming, then we could start with sqrt_floor >> and/or divide. These are unary and binary instructions, respectively, the >> code for which would serve as templates for implementing the other FP >> instructions in the proposal. >> >> If you want to get into the weeds on all this, you can check out the >> relevant Github issue below: >> >> https://github.com/WebAssembly/rounding-mode-control/issues/2 >> >> We haven't signed the CLA yet but we're willing to do so if there's >> interest here. Ask us anything! >> >> Kloud Koder >> >> -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CAKSzg3QOPpr9Q6_PccPcKH8Zygn5ppzjOk5Vk%2BY_ezEbSXNBtA%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAKSzg3QOPpr9Q6_PccPcKH8Zygn5ppzjOk5Vk%2BY_ezEbSXNBtA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Best, Zhi An -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAP2LTJ2Jx%3D6L14TGwZDQscFZe-X77f3ZmdooBSC8BMeDxok-ZQ%40mail.gmail.com.
