Merge pull request #121 from WebAssembly/categorize-ops

Categorize ops previously "under consideration"

2 files changed, 106 insertions, 74 deletions

diff --git a/AstSemantics.md b/AstSemantics.md
index 033a182..b8f85d0 100644
--- a/AstSemantics.md
+++ b/AstSemantics.md
@@ -306,6 +306,9 @@ and 0 representing false.
   * Int32Sle - signed less than or equal
   * Int32Ult - unsigned less than
   * Int32Ule - unsigned less than or equal
+  * Int32Clz - count leading zeroes (defined for all values, including 0)
+  * Int32Ctz - count trailing zeroes (defined for all values, including 0)
+  * Int32Popcnt - count number of ones
 
 Division or remainder by zero traps.
 Signed division overflow (`INT32_MIN / -1`) traps. Signed remainder with a
@@ -320,22 +323,6 @@ Note that greater-than and greater-than-or-equal operations are not required,
 since "a < b" == "b > a" and "a <= b" == "b >= a". Such equalities also hold for
 floating point comparisons, even considering NaN.
 
-Additional 32-bit integer Operations under consideration:
-
-  * Int32SMulHigh - signed multiplication (upper 32-bits)
-  * Int32UMulHigh - unsigned multiplication (upper 32-bits)
-  * Int32Clz - count leading zeroes (defined for all values, including 0)
-  * Int32Ctz - count trailing zeroes (defined for all values, including 0)
-  * Int32Popcnt - count number of ones
-  * Int32BSwap - reverse bytes (endian conversion)
-  * Int32Rotr - bitwise rotate right
-  * Int32Rotl - bitwise rotate left
-  * Int32Not - signed-less one's complement
-  * Int32SMin - signed minimum
-  * Int32SMax - signed maximum
-  * Int32UMin - unsigned minimum
-  * Int32UMax - unsigned maximum
-
 ## Floating point operations
 
 Floating point arithmetic follows the IEEE-754 standard, except that:
@@ -369,10 +356,14 @@ Floating point arithmetic follows the IEEE-754 standard, except that:
   * Float32Copysign - copysign
   * Float32Ceil - ceiling operation
   * Float32Floor - floor operation
+  * Float32Trunc - round to nearest integer towards zero
+  * Float32NearestInt - round to nearest integer, ties to even
   * Float32Eq - compare equal
   * Float32Lt - less than
   * Float32Le - less than or equal
   * Float32Sqrt - square root
+  * Float32Min - minimum (binary operator); if either operand is NaN, returns NaN
+  * Float32Max - maximum (binary operator); if either operand is NaN, returns NaN
 
   * Float64Add - addition
   * Float64Sub - subtraction
@@ -383,28 +374,16 @@ Floating point arithmetic follows the IEEE-754 standard, except that:
   * Float64Copysign - copysign
   * Float64Ceil - ceiling operation
   * Float64Floor - floor operation
+  * Float64Trunc - round to nearest integer towards zero
+  * Float64NearestInt - round to nearest integer, ties to even
   * Float64Eq - compare equal
   * Float64Lt - less than
   * Float64Le - less than or equal
   * Float64Sqrt - square root
+  * Float64Min - minimum (binary operator); if either operand is NaN, returns NaN
+  * Float64Max - maximum (binary operator); if either operand is NaN, returns NaN
 
-Operations under consideration:
-
-  * Float32Min - minimum; if either operand is NaN, returns NaN
-  * Float32Max - maximum; if either operand is NaN, returns NaN
-  * Float32MinNum - minimum; if exactly one operand is NaN, returns the other operand
-  * Float32MaxNum - maximum; if exactly one operand is NaN, returns the other operand
-  * Float32Trunc - round to nearest integer towards zero
-  * Float32NearestInt - round to nearest integer, ties to even
-
-  * Float64Min - minimum; if either operand is NaN, returns NaN
-  * Float64Max - maximum; if either operand is NaN, returns NaN
-  * Float64MinNum - minimum; if exactly one operand is NaN, returns the other operand
-  * Float64MaxNum - maximum; if exactly one operand is NaN, returns the other operand
-  * Float64Trunc - round to nearest integer towards zero
-  * Float64NearestInt - round to nearest integer, ties to even
-
-Min, Max, MinNum, and MaxNum operations would treat -0 as being effectively less than 0.
+Min and Max operations treat -0 as being effectively less than 0.
 
 ## Datatype conversions, truncations, reinterpretations, promotions, and demotions
 
@@ -436,37 +415,3 @@ overflow to infinity or negative infinity as specified by IEEE-754.
 Conversion from floating point to integer where IEEE-754 would specify an
 invalid operation exception (e.g. when the floating point value is NaN or
 outside the range which rounds to an integer in range) traps.
-
-## Post-MVP intrinsics
-
-The following list of intrinsics is being considered for addition after the MVP. The
-rationale is that, for the MVP, these operations can be statically linked into the
-WebAssembly module by the code generator at small size cost and this avoids a
-non-trivial specification burden of their semantics/precision. Adding these
-intrinsics post-MVP would allow for better high-level backend optimization of
-these intrinsics that require builtin knowledge of their semantics. On the other
-hand, a code generator may continue to statically link in its own implementation
-since this provides greater control over precision/performance tradeoffs.
-
-  * Float64Sin - trigonometric sine
-  * Float64Cos - trigonometric cosine
-  * Float64Tan - trigonometric tangent
-  * Float64ASin - trigonometric arcsine
-  * Float64ACos - trigonometric arccosine
-  * Float64ATan - trigonometric  arctangent
-  * Float64ATan2 - trigonometric arctangent with two arguments
-  * Float64Exp - exponentiate e
-  * Float64Ln - natural logarithm
-  * Float64Pow - exponentiate
-  * Float32Sin - trigonometric sine
-  * Float32Cos - trigonometric cosine
-  * Float32Tan - trigonometric tangent
-  * Float32ASin - trigonometric arcsine
-  * Float32ACos - trigonometric arccosine
-  * Float32ATan - trigonometric  arctangent
-  * Float32ATan2 - trigonometric arctangent with two arguments
-  * Float32Exp - exponentiate e
-  * Float32Ln - natural logarithm
-  * Float32Pow - exponentiate
-
-The rounding behavior of these operations would need clarification.
diff --git a/FutureFeatures.md b/FutureFeatures.md
index f8da587..21b3524 100644
--- a/FutureFeatures.md
+++ b/FutureFeatures.md
@@ -152,13 +152,6 @@ include:
 
   [a proposal in the SIMD.js repository]: https://github.com/johnmccutchan/ecmascript_simd/issues/180
 
-## Operations which may not be available or may not perform well on all platforms
-
-* Fused multiply-add.
-* Reciprocal square root approximate.
-* 16-bit floating point.
-* and more!
-
 ## Platform-independent Just-in-Time compilation
 
 WebAssembly is a new virtual ISA, and as such applications won't be able to
@@ -213,3 +206,97 @@ use cases:
     things possible. Possibly this could involve throwing or possibly by
     resuming execution at the trapping instruction with the execution state
     altered, if there can be a reasonable way to specify how that should work.
+
+## Additional integer operations
+
+* The following operations can be built from other operators already present,
+  however in doing so they read at least one non-constant input multiple times,
+  breaking single-use expression tree formation.
+  * Int32Rotr - bitwise rotate right
+  * Int32Rotl - bitwise rotate left
+  * Int32SMin - signed minimum
+  * Int32SMax - signed maximum
+  * Int32UMin - unsigned minimum
+  * Int32UMax - unsigned maximum
+  * Int32SExt - `sext(x, y)` is `x<<y>>y`
+  * Int32Abs - absolute value (is `abs(INT32_MIN)` `INT32_MIN` or should it trap?)
+  * Int32BSwap - reverse bytes (endian conversion)
+  * Int32BSwap16 - `bswap16(x)` is `((x>>8)&255)|((x&255)<<8)`
+
+* The following operations are just potentially interesting.
+  * Int32Clrs - count leading redundant sign bits (defined for all values, including 0)
+
+## Additional floating point operations
+
+  * Float32MinNum - minimum; if exactly one operand is NaN, returns the other operand
+  * Float32MaxNum - maximum; if exactly one operand is NaN, returns the other operand
+  * Float32FMA - fused multiply-add (results always conforming to IEEE-754)
+  * Float64MinNum - minimum; if exactly one operand is NaN, returns the other operand
+  * Float64MaxNum - maximum; if exactly one operand is NaN, returns the other operand
+  * Float64FMA - fused multiply-add (results always conforming to IEEE-754)
+
+MinNum, and MaxNum operations would treat -0 as being effectively less than 0.
+
+Note that some operations, like FMA, may not be available or may not perform
+well on all platforms. These should be guarded by
+[feature tests](FeatureTest.md) so that if available, they behave consistently.
+
+## Floating point approximation operations
+
+  * Float32ReciprocalApproximation - reciprocal approximation
+  * Float64ReciprocalApproximation - reciprocal approximation
+  * Float32ReciprocalSqrtApproximation - reciprocal sqrt approximation
+  * Float64ReciprocalSqrtApproximation - reciprocal sqrt approximation
+
+These operations would not required to be fully precise, but the specifics
+would need clarification.
+
+## 16-bit and 128-bit floating-point support
+
+For 16-bit floating-point support, it may make sense to split the feature
+into two parts: support for just converting between 16-bit and 32-bit or
+64-bit formats possibly folded into load and store operations, and full
+support for actual 16-bit arithmetic.
+
+128-bit is an interesting question because hardware support for it is very
+rare, so it's usually going to be implemented with software emulation anyway,
+so there's nothing preventing WebAssembly applications from linking to an
+appropriate emulation library and getting similarly performant results.
+Emulation libraries would have more flexibility to offer approximation
+techniques such as double-double arithmetic. If we standardize 128-bit
+floating point in WebAssembly, it will probably be standard IEEE-754
+quadruple precision.
+
+## Floating-point library intrinsics
+
+These operations aren't needed because they can be implemented in WebAssembly
+code and linked into WebAssembly modules as at small size cost, and this avoids
+a non-trivial specification burden of their semantics/precision. Adding these
+intrinsics would allow for better high-level backend optimization of these
+intrinsics that require builtin knowledge of their semantics. On the other
+hand, a code generator may continue to statically link in its own
+implementation since this provides greater control over precision/performance
+tradeoffs.
+
+  * Float64Sin - trigonometric sine
+  * Float64Cos - trigonometric cosine
+  * Float64Tan - trigonometric tangent
+  * Float64ASin - trigonometric arcsine
+  * Float64ACos - trigonometric arccosine
+  * Float64ATan - trigonometric  arctangent
+  * Float64ATan2 - trigonometric arctangent with two arguments
+  * Float64Exp - exponentiate e
+  * Float64Ln - natural logarithm
+  * Float64Pow - exponentiate
+  * Float32Sin - trigonometric sine
+  * Float32Cos - trigonometric cosine
+  * Float32Tan - trigonometric tangent
+  * Float32ASin - trigonometric arcsine
+  * Float32ACos - trigonometric arccosine
+  * Float32ATan - trigonometric  arctangent
+  * Float32ATan2 - trigonometric arctangent with two arguments
+  * Float32Exp - exponentiate e
+  * Float32Ln - natural logarithm
+  * Float32Pow - exponentiate
+
+The rounding behavior of these operations would need clarification.