Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove fpenv from overview, add proposed spec text on Relaxed operations #58

Merged
merged 1 commit into from
Mar 1, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 8 additions & 48 deletions proposals/relaxed-simd/Overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,54 +59,14 @@ 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:

```wast
(module
(func (param v128 v128 v128)
(f32x4.qfma $fpu (local.get 0) (local.get 1) (local.get 2)) ;; (1)
;; ...
(f32x4.qfma $fpu (local.get 0) (local.get 1) (local.get 2)) ;; (2)
)
(fpenv $fpu 0))
```

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:

```wast
;; module a
(module
(fpenv $fpu (export "foo") 0)
(func (param v128 v128 v128)
(f32x4.qfma $fpu (local.get 0) (local.get 1) (local.get 2)))) ;; (1)
```

```wast
;; module b
(module
(import "a" "foo" (fpenv $fpu 0))
(func (param v128 v128 v128)
(f32x4.qfma $fpu (local.get 0) (local.get 1) (local.get 2)))) ;; (2)
```

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.
The specification is updated with the idea of "Relaxed operations":

> Some operators are host-dependent, because the set of possible results may
> depend on properties of the host environment (such as hardware). Technically,
> each such operator produces a fixed-size list of sets of allowed values. For
> each execution of the operator in the same environment, only values from the
> set at the same position in the list are returned, i.e., each environment
> globally chooses a fixed projection for each operator.

## Instructions

Expand Down