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.
