Should we define a scalar intrinsics header?

[tlively]

@Maratyszcza suggested to me that we should have a portable intrinsics header for non-SIMD WebAssembly instructions that are not directly expressible in C, so I wanted to gauge wider interest in such a header. On hand there is only one production C/C++ compiler for WebAssembly at the moment so portability isn't so important, but on the other hand it may be important in the future and having proper intrinsics is certainly more ergonomic than writing __builtin_wasm_* everwhere. What do people think?

There is precedent for scalar intrinsics on other platforms, for example arm_acle.h documented in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf.

Some instructions such a header would include would be i32.clz, i32.ctz, i32.popcnt, i32.shr_s, i32.rotl, i32.rotr, f32.min, f32.max, etc.

[sunfishcode]

My preference would be to not add a header file. We already have most instructions covered:

• some via target-independent builtins like __builtin_clz
• some via wasm-specific ones like __builtin_wasm_min_f32 (though now with IEEE 754-2019, we could probably add target-independent versions of min/max) and __builtin_wasm_memory_grow
• some with pattern-matching like shr_s (which isn't perfect, but to the extent that it isn't, we can always add more __builtin_wasm_* functions as needed).

__builtin_-style functions on other targets are already common between clang, GCC, and other compilers, so it seems reasonable to expect any new C compiler targeting WebAssembly to support them as well if it wants to be compatible with existing codebases.