1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
See [rationale](Rationale.md#feature-testing---motivating-scenarios) for motivating scenarios.
# Feature Test
[Post-MVP :unicorn:][future general], applications will be able to query which features are
supported via
[`has_feature` or a similar API :unicorn:][future feature testing]. This
accounts for the pragmatic reality that features are shipped in different orders
at different times by different engines.
What follows is a sketch of what such a feature testing capability could look
like.
Since some WebAssembly features add operators and all WebAssembly code in a
module is validated ahead-of-time, the usual JavaScript feature detection
pattern:
```
if (foo)
foo();
else
alternativeToFoo();
```
won't work in WebAssembly (if `foo` isn't supported, `foo()` will fail to
validate).
Instead, applications may use one of the following strategies:
1. Compile several versions of a module, each assuming different feature support
and use `has_feature` tests to determine which version to load.
2. During the ["specific" layer decoding](BinaryEncoding.md), which will happen
in user code in the MVP *anyway*, use `has_feature` to determine which features
are supported and then translate unsupported feature use into either a polyfill
or a trap.
Both of these options could be automatically provided by the toolchain and
controlled by compiler flags. Since `has_feature` is a constant expression,
it can be constant-folded by WebAssembly engines.
To illustrate, consider 4 examples:
* [`i32.min_s` :unicorn:][future integer] - Strategy 2
could be used to translate `(i32.min_s lhs rhs)` into an equivalent expression
that stores `lhs` and `rhs` in locals then uses `i32.lt_s` and `select`.
* [Threads :unicorn:][future threads] - If an application uses `#ifdef` extensively
to produce thread-enabled/disabled builds, Strategy 1 would be appropriate.
However, if the application was able to abstract use of threading to a few
primitives, Strategy 2 could be used to patch in the right primitive
implementation.
* [`mprotect` :unicorn:][future memory control] - If engines
aren't able to use OS signal handling to implement `mprotect` efficiently,
`mprotect` may become a permanently optional feature. For uses of `mprotect`
that are not necessary for correctness (but rather just catching bugs),
`mprotect` could be replaced with `nop`. If `mprotect` was necessary for
correctness but an alternative strategy existed that did not rely on
`mprotect`, `mprotect` could be replaced with an `abort()` call, relying on
the application to test `(has_feature "mprotect")` to avoid calling the
`abort()`. The `has_feature` query could be exposed to C++ code via
the existing `__builtin_cpu_supports`.
* [SIMD][future simd] - When SIMD operators have a good-enough
polyfill, e.g., `f32x4.fma` via `f32x4.mul`/`add`, Strategy 2 could be used
(similar to the `i32.min_s` example above). However, when a SIMD feature has no
efficient polyfill (e.g., `f64x2`, which introduces both operators *and*
types), alternative algorithms need to be provided and selected at load time.
As a hypothetical (not implemented) example polyfilling the SIMD `f64x2`
feature, the C++ compiler could provide a new function attribute that indicated
that one function was an optimized, but feature-dependent, version of another
function (similar to the
[`ifunc` attribute](https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#index-g_t_0040code_007bifunc_007d-attribute-2529),
but without the callback):
```
#include <xmmintrin.h>
void foo(...) {
__m128 x, y; // -> f32x4 locals
...
x = _mm_add_ps(x, y); // -> f32x4.add
...
}
void foo_f64x2(...) __attribute__((optimizes("foo","f64x2"))) {
__m256 x, y; // -> f64x2 locals
...
x = _m_add_pd(x, y); // -> f64x2.add
...
}
...
foo(...); // calls either foo or foo_f64x2
```
In this example, the toolchain could emit both `foo` and `foo_f64x2` as
function definitions in the "specific layer" binary format. The load-time
polyfill would then replace `foo` with `foo_f64x2` if
`(has_feature "f64x2")`. Many other strategies are possible to allow finer or
coarser granularity substitution. Since this is all in userspace, the strategy
can evolve over time.
See also the [better feature testing support :unicorn:][future feature testing]
future feature.
[future general]: FutureFeatures.md
[future feature testing]: FutureFeatures.md#feature-testing
[future integer]: FutureFeatures.md#additional-integer-operators
[future threads]: https://github.com/WebAssembly/design/issues/1073
[future simd]: https://github.com/WebAssembly/design/issues/1075
[future memory control]: FutureFeatures.md#finer-grained-control-over-memory
|
