This proposal introduces non-deterministic instructions - given the same

inputs, two calls to the same instruction can return different results. For

example:

The same instruction at `(1)` and `(2)`, when given the same inputs, can return

two different results. This is compliant as the instruction is

non-deterministic, though unlikely on certain embeddings like the Web (where

the same implementation for `f32x4.qfma` is likely to be used for all calls to

that instruction). One can imagine splitting an application's module and

running them on multiple runtimes, where the runtimes produce

different results - this can be surprising to the application.

Applications can specify their consistency needs using a new module-level

entity `fpenv` (name subject to change). A `fpenv` is defined in the `fpenv`

section of a module. All Relaxed SIMD instructions will take an additional

`varuint32` immediate, which is an index into the `fpenv` index space:

In the example above, both `f32x4.qfma` instructions refer to the same `fpenv`,

and will get the same results when given the same input.

A `fpenv` has a single `varuint32` attribute which is reserved for future

extensibility and must be `0` for now. The value of an `fpenv` is

non-deterministically computed when the module which declares it is

instantiated. This value determines the semantics of the instructions that

uses it as an immediate.

As such, all the non-determinism of Relaxed SIMD is encapsulated in `fpenv`,

which makes Relaxed SIMD instructions themselves deterministic.

Modules can import/export an `fpenv` to specify consistency requirements:

In the above example, the same `fpenv` is exported by module `a`, and imported

by module `b`, so instructions `(1)` and `(2)` will consistently return the

same results when given the same inputs.