Jakob and Zhi An,

Thanks for the details. We think this gives us a sufficient basis to pursue
a prototype integration on V8. We'll try to submit a pull request in due
course.

Kloud Koder


On Thu, May 23, 2024 at 1:19 AM 'Zhi An Ng' via v8-dev <
[email protected]> wrote:

> 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 <[email protected]>
> 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 <[email protected]>
>> 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
>> [email protected]
>> 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 [email protected].
>> 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
> [email protected]
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-dev/CAP2LTJ2Jx%3D6L14TGwZDQscFZe-X77f3ZmdooBSC8BMeDxok-ZQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/v8-dev/CAP2LTJ2Jx%3D6L14TGwZDQscFZe-X77f3ZmdooBSC8BMeDxok-ZQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
v8-dev mailing list
[email protected]
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-dev/CAB_Hu_a1geA--zPvj2Siz%3D-JpcbH921Kzw7%3D1RnF2Zg2i-Uz_A%40mail.gmail.com.

Reply via email to