Merge pull request #265 from WebAssembly/jit-library

Add a page about a JIT/Optimization library idea.

1 files changed, 6 insertions, 46 deletions

diff --git a/FutureFeatures.md b/FutureFeatures.md
index 0391ed2..1604636 100644
--- a/FutureFeatures.md
+++ b/FutureFeatures.md
@@ -171,7 +171,7 @@ include:
 
   [a proposal in the SIMD.js repository]: https://github.com/tc39/ecmascript_simd/issues/180
 
-## Platform-independent Just-in-Time compilation
+## Platform-independent Just-in-Time (JIT) compilation
 
 WebAssembly is a new virtual ISA, and as such applications won't be able to
 simply reuse their existing JIT-compiler backends. Applications will instead
@@ -195,6 +195,11 @@ should support:
 * Code unloading capabilities, especially in the context of code garbage
   collection and defragmentation.
 
+WebAssembly's JIT interface would likely be fairly low-level. However, there
+are use cases for higher-level functionality and optimization too. One avenue
+for addressing these use cases is a
+[JIT and Optimization library](JITLibrary.md).
+
 ## Multiprocess support
 
 * `vfork`.
@@ -287,51 +292,6 @@ 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 for the MVP because they can be implemented in
-WebAssembly code and linked into WebAssembly modules at small size cost (as is
-traditionally done through C libraries such as libm). This approach:
-
-* Avoids a non-trivial specification burden for their semantics, precision, and
-  performance.
-* Allows developers to make different application-specific tradeoffs of
-  precision/robustness versus performance, while still getting deterministic
-  results across implementations.
-* Reduces the implementation burden for WebAssembly, since more than the few
-  math functions listed below may be needed by different developers.
-
-[Dynamic linking](FutureFeatures.md#dynamic-linking) will also allow caching of
-libm, making this already low-cost sharing trivial.
-
-Adding these intrinsics would potentially allow for better high-level backend
-optimization of these intrinsics that require builtin knowledge of their
-semantics. WebAssembly may support these operations in the future if data shows
-it would be useful. The rounding behavior of these operations would need
-clarification.
-
-
-  * `float64.sin`: trigonometric sine
-  * `float64.cos`: trigonometric cosine
-  * `float64.tan`: trigonometric tangent
-  * `float64.asin`: trigonometric arcsine
-  * `float64.acos`: trigonometric arccosine
-  * `float64.atan`: trigonometric  arctangent
-  * `float64.atan2`: trigonometric arctangent with two arguments
-  * `float64.exp`: exponentiate e
-  * `float64.ln`: natural logarithm
-  * `float64.pow`: exponentiate
-  * `float32.sin`: trigonometric sine
-  * `float32.cos`: trigonometric cosine
-  * `float32.tan`: trigonometric tangent
-  * `float32.asin`: trigonometric arcsine
-  * `float32.acos`: trigonometric arccosine
-  * `float32.atan`: trigonometric  arctangent
-  * `float32.atan2`: trigonometric arctangent with two arguments
-  * `float32.exp`: exponentiate e
-  * `float32.ln`: natural logarithm
-  * `float32.pow`: exponentiate
-
 ## Full IEEE-754 conformance
 
 WebAssembly floating point conforms IEEE-754 in most respects, but there are a