Merge pull request #265 from WebAssembly/jit-library

Add a page about a JIT/Optimization library idea.

3 files changed, 94 insertions, 47 deletions

diff --git a/FAQ.md b/FAQ.md
index c02c61d..ef756b9 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -220,7 +220,7 @@ WebAssembly implementations run on the user side, so there is no opportunity for
 
  * Many of the important fast-math optimizations happen in the mid-level optimizer of a compiler, before WebAssembly code is emitted. For example, loop vectorization that depends on floating point reassociation can still be done at this level if the user applies the appropriate fast-math flags, so WebAssembly programs can still enjoy these benefits. As another example, compilers can replace floating point division with floating point multiplication by a reciprocal in WebAssembly programs just as they do for other platforms.
 
- * Mid-level compiler optimizations may also be augmented by implementing them in a JIT library in WebAssembly. This would allow them to perform optimizations that benefit from having [information about the target](FeatureTest.md) and information about the source program semantics such as fast-math flags at the same time. For example, if SIMD types wider than 128-bit are added, it's expected that there would be feature tests allowing WebAssembly code to determine which SIMD types to use on a given platform.
+ * Mid-level compiler optimizations may also be augmented by implementing them in a [JIT library](JITLibrary.md) in WebAssembly. This would allow them to perform optimizations that benefit from having [information about the target](FeatureTest.md) and information about the source program semantics such as fast-math flags at the same time. For example, if SIMD types wider than 128-bit are added, it's expected that there would be feature tests allowing WebAssembly code to determine which SIMD types to use on a given platform.
 
  * When WebAssembly [adds an FMA operation](FutureFeatures.md#additional-floating-point-operations), folding multiply and add sequences into FMA operators will be possible.
 
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
diff --git a/JITLibrary.md b/JITLibrary.md
new file mode 100644
index 0000000..71167c5
--- /dev/null
+++ b/JITLibrary.md
@@ -0,0 +1,87 @@
+# JIT and Optimization Library
+
+WebAssembly's
+[Just-in-Time compilation (JIT)](FutureFeatures.md#platform-independent-just-in-time-jit-compilation)
+interface will likely be fairly low-level, exposing general-purpose primitives
+rather than higher-level functionality. Still, there is a need for higher-level
+functionality, and for greater flexibility than the WebAssembly spec can provide.
+There is also a need for experimentation, particularly in the area of
+applications wishing to dynamically generate new code, to determine which features
+and interfaces are most appropriate. JIT and Optimization libraries that would run
+inside WebAssembly and provide support and higher-level features would fit this
+need very well.
+
+Such libraries wouldn't be part of the WebAssembly spec itself, but the concept
+is relevant to discuss here because features that we can expect to address in
+libraries are features that we may not need to add to the spec. This strategy
+can help keep the spec itself simple and reduce the surface area of features
+required of every spec implementation.
+
+And, libraries will facilitate light-weight experimentation with new features
+that we may eventually want to add to WebAssembly itself. In a library layer,
+we can quickly iterate, experiment, and gain real-world insight, before adding
+features to the spec itself and freezing all the details. And as new features
+are standardized, libraries will become the polyfills which will help those
+features gain adoption.
+
+This raises the question of how we should decide which features belong in the
+spec, and which belong in a library. Some of the fundamental advantages of
+putting functionality in a library rather than in the spec and in implementations
+themselves include:
+
+ * A library can freely choose to offer greater degrees of undefined behavior,
+   implementation-defined behavior, unspecified behavior, and so on. This means
+   it can perform much more aggressive optimizations, including many that are
+   extremely common in optimizing compilers and might otherwise seem missing in
+   the WebAssembly spec itself:
+    * Constant folding, strength reduction, and code motion of math functions
+      such as `sin`, `cos`, `exp`, `log`, `pow`, and `atan2`.
+    * Performing aggressive expression simplifications that depend on assuming
+      that integer arithmetic doesn't overflow.
+    * Performing GVN with redundant load elimination, and other optimizations
+      based on aliasing rules that incur undefined behavior if they are violated.
+    * Vectorization that utilizes both floating point reassociation and
+      awareness of the underlying platform through
+      [feature testing](FeatureTest.md).
+
+ * A library can support higher-level features, and features that are tailored
+   to certain applications, whereas the WebAssembly spec itself is limited to
+   general-purpose primitives. Possible examples of this are:
+    * A richer type system, which could include things like complex, rational,
+      arbitrary bitwidth integers, non-power-of-2 SIMD types, interval
+      arithmetic, etc.
+    * A higher-level type system, which could include basic polymorphism of
+      various kinds (either with true dynamism or with monomorphisation).
+    * Richer control flow constructs.
+    * A broader set of operations, such as string-handling operations,
+      data type serialization, testing facilities, and linear algebra
+      operations, all of which can benefit from being integrated at the
+      language level.
+   Since every feature required in the spec itself will need to be implemented
+   by all implementations, domain-specific features run the risk of making
+   people "pay for what they don't use". With features libraries, people need
+   only pay for the features they choose to use.
+
+ * A library can evolve over time to meet the changing needs of higher-level
+   languages. In practice, compiler IRs such as LLVM IR evolve to add new
+   features, change existing features, and sometimes remove features, and these
+   kinds of changes are much harder to do in a spec.
+
+The library approach also means that applications using a particular version
+of a library can get consistent behavior and performance, because of the
+determinism of the underlying WebAssembly platform.
+
+A significant range of approaches are possible:
+
+  * "Customized WebAssembly". This might involve a library whose input format
+    is conceptually WebAssembly but with some additional features. The library
+    could optimize and then lower those features leaving standard WebAssembly
+    to present to the underlying implementation.
+
+  * "Bring Your Own Compiler" There's nothing stopping one from bundling
+    full-fledged AOT-style compilers that compile an independent source language
+    or IR into WebAssembly right there in WebAssembly itself. Obviously this
+    will involve tradeoffs in terms of download size and startup time, but it
+    would allow a unique degree of flexibility.
+
+  * And many things in between.