Relaxed SIMD

.github/workflows/ci-interpreter.yml

@@ -27,7 +27,7 @@ jobs:
       - name: Setup Node.js
         uses: actions/setup-node@v2
         with:
-          node-version: 19.x
+          node-version: 20.x
       - name: Build interpreter
         run: cd interpreter && opam exec make
       - name: Run tests

document/core/appendix/changes.rst

@@ -518,6 +518,48 @@ Added managed reference types. [#proposal-gc]_
   - |EXTERNCONVERTANY|
 
 
+.. index:: instruction, vector instruction, SIMD
+
+Relaxed Vector Instructions
+...........................
+
+Added new *relaxed* vector instructions,
+whose behaviour is non-deterministic and implementation-dependent. [#proposal-relaxed]_
+
+* New binary :ref:`vector instruction <syntax-instr-vec-relaxed>`:
+
+  - :math:`\K{f}\!N\!\K{x}\!M\!\K{.relaxed\_min}`
+  - :math:`\K{f}\!N\!\K{x}\!M\!\K{.relaxed\_max}`
+  - :math:`\K{i16x8.relaxed\_q15mulr\_s}`
+  - :math:`\K{i16x8.relaxed\_dot\_i8x16\_i7x16\_s}`
+
+* New ternary :ref:`vector instruction <syntax-instr-vec-relaxed>`:
+
+  - :math:`\K{f}\!N\!\K{x}\!M\!\K{.relaxed\_madd}`
+  - :math:`\K{f}\!N\!\K{x}\!M\!\K{.relaxed\_nmadd}`
+  - :math:`\K{i}\!N\!\K{x}\!M\!\K{.relaxed\_laneselect}`
+  - :math:`\K{i32x4.relaxed\_dot\_i8x16\_i7x16\_add\_s}`
+
+* New conversion :ref:`vector instructions <syntax-instr-vec-relaxed>`:
+
+  - :math:`\K{i32x4.relaxed\_trunc\_f32x4\_}\sx`
+  - :math:`\K{i32x4.relaxed\_trunc\_f64x2\_}\sx\K{\_zero}`
+
+* New byte reordering :ref:`vector instruction <syntax-instr-vec-relaxed>`:
+
+  - :math:`\K{i8x16.relaxed\_swizzle}`
+
+
+.. index:: determinism, non-determinism, profiles
+
+Profiles
+........
+
+Introduced the concept of :ref:`profile <profiles>` for specifying language subsets.
+
+* A new profile defining a :ref:`deterministic <profile-deterministic>` mode of execution.
+
+
 .. index:: text format, annotation, custom section, identifier, module, type, function, local, structure field
 
 Custom Annotations
@@ -542,7 +584,7 @@ mirroring the role of custom sections in the binary format. [#proposal-annot]_
 
 
 .. [#proposal-extconst]
-   https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/
+   https://github.com/WebAssembly/spec/blob/main/proposals/extended-const/
 
 .. [#proposal-tailcall]
    https://github.com/WebAssembly/spec/tree/main/proposals/tail-call/
@@ -551,13 +593,16 @@ mirroring the role of custom sections in the binary format. [#proposal-annot]_
    https://github.com/WebAssembly/spec/tree/main/proposals/exception-handling/
 
 .. [#proposal-multimem]
-   https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/
+   https://github.com/WebAssembly/spec/blob/main/proposals/multi-memory/
 
 .. [#proposal-typedref]
    https://github.com/WebAssembly/spec/tree/main/proposals/function-references/
 
 .. [#proposal-gc]
    https://github.com/WebAssembly/spec/tree/main/proposals/gc/
 
+.. [#proposal-relaxed]
+   https://github.com/WebAssembly/spec/tree/main/proposals/relaxed-simd/
+
 .. [#proposal-annot]
    https://github.com/WebAssembly/annotations/tree/main/proposals/annotations/

document/core/appendix/index.rst

@@ -7,6 +7,7 @@ Appendix
    :maxdepth: 2
 
    embedding
+   profiles
    implementation
    properties
    algorithm

document/core/appendix/profiles.rst

@@ -0,0 +1,131 @@
+.. index:: ! profile, abstract syntax, validation, execution, binary format, text format
+.. _profiles:
+
+Profiles
+--------
+
+To enable the use of WebAssembly in as many environments as possible, *profiles* specify coherent language subsets that fit constraints imposed by common classes of host environments.
+A host platform can thereby decide to support the language only under a restricted profile, or even the intersection of multiple profiles.
+
+
+Conventions
+~~~~~~~~~~~
+
+A profile modification is specified by decorating selected rules in the main body of this specification with a *profile annotation* that defines them as conditional on the choice of profile.
+
+For that purpose, every profile defines a *profile marker*, an alphanumeric short-hand like :math:`\profilename{ABC}`.
+A profile annotation of the form :math:`\exprofiles{\profile{ABC}~\profile{XYZ}}` on a rule indicates that this rule is *excluded* for either of the profiles whose marker is :math:`\profilename{ABC}` or :math:`\profilename{XYZ}`.
+
+There are two ways of subsetting the language in a profile:
+
+* *Syntactic*, by *omitting* a feature, in which case certain constructs are removed from the syntax altogether.
+
+* *Semantic*, by *restricting* a feature, in which case certain constructs are still present but some behaviours are ruled out.
+
+
+Syntax Annotations
+..................
+
+To omit a construct from a profile syntactically, respective productions in the grammar of the :ref:`abstract syntax <syntax>` are annotated with an associated profile marker.
+This is defined to have the following implications:
+
+1. Any production in the :ref:`binary <binary>` or :ref:`textual <text>` syntax that produces abstract syntax with a marked construct is omitted by extension.
+
+2. Any :ref:`validation <valid>` or :ref:`execution <exec>` rule that handles a marked construct is omitted by extension.
+
+The overall effect is that the respective construct is no longer part of the language under a respective profile.
+
+.. note::
+   For example, a "busy" profile marked :math:`\profilename{BUSY}` could rule out the |NOP| instruction by marking the production for it in the abstract syntax as follows:
+
+   .. math::
+      \begin{array}{llcl}
+      \production{instruction} & \instr &::=&
+        \dots \\
+      & \exprofiles{\profile{BUSY}} &|& \NOP \\
+      &                           &|& \UNREACHABLE \\
+      \end{array}
+
+   A rule may be annotated by multiple markers, which could be the case if a construct is in the intersection of multiple features.
+
+
+Semantics Annotations
+.....................
+
+To restrict certain behaviours in a profile, individual :ref:`validation <valid>` or :ref:`reduction <exec>` rules or auxiliary definitions are annotated with an associated marker.
+
+This has the consequence that the respective rule is no longer applicable under the given profile.
+
+.. note::
+   For example, an "infinite" profile marked :math:`\profilename{INF}` could define that growing memory never fails:
+
+   .. math::
+	   \begin{array}{llcl@{\qquad}l}
+	   & S; F; (\I32.\CONST~n)~\MEMORYGROW~x &\stepto& S'; F; (\I32.\CONST~\X{sz})
+	   \\&&&
+	     \begin{array}[t]{@{}r@{~}l@{}}
+	     (\iff & F.\AMODULE.\MIMEMS[x] = a \\
+	     \wedge & \X{sz} = |S.\SMEMS[a].\MIDATAS|/64\,\F{Ki} \\
+	     \wedge & S' = S \with \SMEMS[a] = \growmem(S.\SMEMS[a], n)) \\[1ex]
+	     \end{array}
+	   \\[1ex]
+	   \exprofiles{\profile{INF}} & S; F; (\I32.\CONST~n)~\MEMORYGROW~x &\stepto& S; F; (\I32.\CONST~\signed_{32}^{-1}(-1))
+	   \end{array}
+
+
+Properties
+..........
+
+All profiles are defined such that the following properties are preserved:
+
+* All profiles represent syntactic and semantic subsets of the :ref:`full profile <profile-full>`, i.e., they do not *add* syntax or *alter* behaviour.
+
+* All profiles are mutually compatible, i.e., no two profiles subset semantic behaviour in inconsistent or ambiguous ways, and any intersection of profiles preserves the properties described here.
+
+* Profiles do not violate :ref:`soundness <soundness>`, i.e., all :ref:`configurations <syntax-config>` valid under that profile still have well-defined execution behaviour.
+
+.. note::
+   Tools are generally expected to handle and produce code for the full profile by default.
+   In particular, producers should not generate code that *depends* on specific profiles. Instead, all code should preserve correctness when executed under the full profile.
+
+   Moreover, profiles should be considered static and fixed for a given platform or ecosystem. Runtime conditioning on the "current" profile is not intended and should be avoided.
+
+
+
+Defined Profiles
+~~~~~~~~~~~~~~~~
+
+.. note::
+   The number of defined profiles is expected to remain small in the future. Profiles are intended for broad and permanent use cases only. In particular, profiles are not intended for language versioning.
+
+
+.. index:: full profile
+   single: profile; full
+.. _profile-full:
+
+Full Profile (:math:`{\small{\mathrm{FUL}}}`)
+.............................................
+
+The *full* profile contains the complete language and all possible behaviours.
+It imposes no restrictions, i.e., all rules and definitions are active.
+All other profiles define sub-languages of this profile.
+
+
+.. index:: determinism, non-determinism, deterministic profile
+   single: profile; deterministic
+.. _profile-deterministic:
+
+Deterministic Profile (:math:`{\small{\mathrm{DET}}}`)
+......................................................
+
+The *deterministic* profile excludes all rules marked :math:`\exprofiles{\PROFDET}`.
+It defines a sub-language that does not exhibit any incidental non-deterministic behaviour:
+
+* All :ref:`NaN <syntax-nan>` values :ref:`generated <aux-nans>` by :ref:`floating-point instructions <syntax-instr-numeric>` are canonical and positive.
+
+* All :ref:`relaxed vector instructions <syntax-instr-vec-relaxed>` have a fixed behaviour that does not depend on the implementation.
+
+Even under this profile, the |MEMORYGROW| and |TABLEGROW| instructions technically remain :ref:`non-deterministic <exec-memory.grow>`, in order to be able to indicate resource exhaustion.
+
+.. note::
+   In future versions of WebAssembly, new non-deterministic behaviour may be added to the language, such that the deterministic profile will induce additional restrictions.

document/core/binary/instructions.rst

@@ -258,6 +258,7 @@ The ${:CONST} instruction for vectors is followed by 16 immediate bytes, which a
 
 $${grammar: Binstr/vec-const}
 
+.. _binary-vswizzlop:
 .. _binary-vshuffle:
 
 The ${:SHUFFLE} instruction is also followed by the encoding of 16 ${:laneidx} immediates.
@@ -309,6 +310,10 @@ $${grammar: {
 .. _binary-vshiftop:
 .. _binary-viunop:
 .. _binary-vibinop:
+.. _binary-viternop:
+.. _binary-viextunop:
+.. _binary-viextbinop:
+.. _binary-viextternop:
 .. _binary-viminmaxop:
 .. _binary-vsatbinop:
 
@@ -342,6 +347,7 @@ $${grammar: {
   Binstr/vec-shift-i32x4
   Binstr/vec-bin-i32x4
   Binstr/vec-extbin-i32x4
+  Binstr/vec-exttern-i32x4
 }}
 
 $${grammar: {
@@ -356,19 +362,47 @@ $${grammar: {
 
 .. _binary-vfunop:
 .. _binary-vfbinop:
+.. _binary-vfternop:
 
 $${grammar: {
   Binstr/vec-un-f32x4
   Binstr/vec-bin-f32x4
+  Binstr/vec-tern-f32x4
 }}
 
 $${grammar: {
   Binstr/vec-un-f64x2
   Binstr/vec-bin-f64x2
+  Binstr/vec-tern-f64x2
 }}
 
 $${grammar: {Binstr/vec-cvt}}
 
+.. math::
+   \begin{array}{llclll}
+   \phantom{\production{instruction}} & \phantom{\Binstr} &\phantom{::=}& \phantom{\dots} && \phantom{vechaslongerinstructionnames} \\[-2ex] &&|&
+     \hex{FD}~~256{:}\Bu32 &\Rightarrow& \I16X8.\VRELAXEDSWIZZLE \\ &&|&
+     \hex{FD}~~257{:}\Bu32 &\Rightarrow& \I32X4.\VRELAXEDTRUNC\K{\_f32x4\_s} \\ &&|&
+     \hex{FD}~~258{:}\Bu32 &\Rightarrow& \I32X4.\VRELAXEDTRUNC\K{\_f32x4\_u} \\ &&|&
+     \hex{FD}~~259{:}\Bu32 &\Rightarrow& \I32X4.\VRELAXEDTRUNC\K{\_f32x4\_s\_zero} \\ &&|&
+     \hex{FD}~~260{:}\Bu32 &\Rightarrow& \I32X4.\VRELAXEDTRUNC\K{\_f32x4\_u\_zero} \\ &&|&
+     \hex{FD}~~261{:}\Bu32 &\Rightarrow& \F32X4.\VRELAXEDMADD \\ &&|&
+     \hex{FD}~~262{:}\Bu32 &\Rightarrow& \F32X4.\VRELAXEDNMADD \\ &&|&
+     \hex{FD}~~263{:}\Bu32 &\Rightarrow& \F64X2.\VRELAXEDMADD \\ &&|&
+     \hex{FD}~~264{:}\Bu32 &\Rightarrow& \F64X2.\VRELAXEDNMADD \\ &&|&
+     \hex{FD}~~265{:}\Bu32 &\Rightarrow& \I8X16.\VRELAXEDLANESELECT \\ &&|&
+     \hex{FD}~~266{:}\Bu32 &\Rightarrow& \I16X8.\VRELAXEDLANESELECT \\ &&|&
+     \hex{FD}~~267{:}\Bu32 &\Rightarrow& \I32X4.\VRELAXEDLANESELECT \\ &&|&
+     \hex{FD}~~268{:}\Bu32 &\Rightarrow& \I64X2.\VRELAXEDLANESELECT \\ &&|&
+     \hex{FD}~~269{:}\Bu32 &\Rightarrow& \F32X4.\VRELAXEDMIN \\ &&|&
+     \hex{FD}~~270{:}\Bu32 &\Rightarrow& \F32X4.\VRELAXEDMAX \\ &&|&
+     \hex{FD}~~271{:}\Bu32 &\Rightarrow& \F64X2.\VRELAXEDMIN \\ &&|&
+     \hex{FD}~~272{:}\Bu32 &\Rightarrow& \F64X2.\VRELAXEDMAX \\ &&|&
+     \hex{FD}~~273{:}\Bu32 &\Rightarrow& \I16X8.\VRELAXEDQ15MULR\K{\_s} \\ &&|&
+     \hex{FD}~~274{:}\Bu32 &\Rightarrow& \I16X8.\VRELAXEDDOT\K{\_i8x16\_i7x16\_s} \\ &&|&
+     \hex{FD}~~275{:}\Bu32 &\Rightarrow& \I16X8.\VRELAXEDDOT\K{\_i8x16\_i7x16\_add\_s} \\
+   \end{array}
+
 
 .. index:: expression
    pair: binary format; expression