I agree that the SIMD use cases that this proposal addresses are compelling and should be addressed. However, I haven't seen any really compelling use cases outside of SIMD. All the other features I can think of (GC, threads, exception handling, ...) seem like cases where conditional sections wouldn't be enough -- you'd want to compile wholly different modules.
If our only real motivation is SIMD (and other instructions that have the same "instructions that optimize what you can already do" character), it seems like there is a simpler design that avoids much of the complication and compatibility hazards of conditional-sections.
In particular, with SIMD (and similar kinds of instructions), validation is very easy to implement; the hard thing is compiling SIMD when you don't have good hardware support. Thus, we could say that:
- an engine without hardware SIMD was allowed to compile SIMD instructions to traps
- a new
bool(i32)-producing constant-valued testing instruction was added returning whether SIMD instructions were, in this instance, compiled to traps
- if (now or in the future) there were different groups of instructions (with different levels of hardware support), multiple testing instructions could be added (with a spec-defined correspondence between which tests covered which instructions)
Thus the burden is on the compiler to guard SIMD instructions with suitable branches and providing a fallback to non-SIMD. Since the tests are constant-valued, an optimizing compiler should have no problem eliminating the dead branch and so there should be no appreciable difference in performance vs. the more #ifdef-y conditional-sections proposal. In fact, by not requiring the branch to happen at function boundaries, this approach could enable SIMD to be used more liberally "in line" without incurring function call costs (or depending on wasm engines performing function inlining, which they generally avoid doing).
What's nice about this approach is:
- all code is validated on every engine
- the spec now has a small, fixed set of host-defined parameters
- there is a natural pressure to minimize the set of host-defined parameters to only those that, like SIMD, have a compelling reason, instead of whatever's convenient (which can easily lead to a proliferation of parameters and thus incompatibility)
One thing I realized during the discussion at the last CG f2f that I didn't realize in #9, is that, even with the move toward explicit parameters, in the absence of a JS host, a pure-wasm implementation has to define the set of parameter values itself making the choice of parameters actually part of the "standard" that any wasm host must implement to portably run content. If there is a standard, it seems better to be explicit and intentional about it.
I agree that the SIMD use cases that this proposal addresses are compelling and should be addressed. However, I haven't seen any really compelling use cases outside of SIMD. All the other features I can think of (GC, threads, exception handling, ...) seem like cases where conditional sections wouldn't be enough -- you'd want to compile wholly different modules.
If our only real motivation is SIMD (and other instructions that have the same "instructions that optimize what you can already do" character), it seems like there is a simpler design that avoids much of the complication and compatibility hazards of conditional-sections.
In particular, with SIMD (and similar kinds of instructions), validation is very easy to implement; the hard thing is compiling SIMD when you don't have good hardware support. Thus, we could say that:
bool(i32)-producing constant-valued testing instruction was added returning whether SIMD instructions were, in this instance, compiled to trapsThus the burden is on the compiler to guard SIMD instructions with suitable branches and providing a fallback to non-SIMD. Since the tests are constant-valued, an optimizing compiler should have no problem eliminating the dead branch and so there should be no appreciable difference in performance vs. the more
#ifdef-y conditional-sections proposal. In fact, by not requiring the branch to happen at function boundaries, this approach could enable SIMD to be used more liberally "in line" without incurring function call costs (or depending on wasm engines performing function inlining, which they generally avoid doing).What's nice about this approach is:
One thing I realized during the discussion at the last CG f2f that I didn't realize in #9, is that, even with the move toward explicit parameters, in the absence of a JS host, a pure-wasm implementation has to define the set of parameter values itself making the choice of parameters actually part of the "standard" that any wasm host must implement to portably run content. If there is a standard, it seems better to be explicit and intentional about it.