Attached is a simple FFT program written in C with SIMD intrinsics. It was originally from [0]; the attached version is the version maintained in the LLVM test-suite [1]. This is an example of a program which we want Emscripten to be able to compile with the new SIMD.js support, with asm.js validation, and with good performance. With the very latest Emscripten incoming branch, the only operations that are missing for this program to validate as asm.js are load, store, shuffle, and shuffleMix. For load and store, we can use the new load and store functions recently added to the SIMD.js spec. I filed bug 1079361. For shuffle and shuffleMix, we need bug 1059408, though I expect we'll want to implement the proposed shuffles outlined in [2] sooner rather than later. For full validation, we also currently need to pass "-s PRECISE_F32=1" or similar to Emscripten to ensure that Math.fround calls are inserted in places where asm.js SIMD validation needs them. There are possible ways we could avoid this requirement, but it depends on the resolution of bug 1077175. [0] http://people.inf.ethz.ch/arbenz/book/ [1] http://llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c?revision=103209&view=co [2] https://github.com/johnmccutchan/ecmascript_simd/issues/74

Dan, do you need more features in asm.js for this particular demo? More generally, what are other SIMD features that would be needed for emscripten / asm.js?

It looks like it's getting close. Compiling with "emcc -O2 sse.expandfft.c -s PRECISE_F32=1 -g" and replacing the "almost asm" to "use asm", I get the attached a.out.js. Running under the latest OdinMonkey, I now get this: a.out.js:12285:29 warning: asm.js type error: expected Uint8Array view as SIMD.*.store first argument Line 12285 is this: $33 = SIMD_float32x4_load(HEAP8, $y + ($mul101$us << 3) | 0); which is a load, not a store, and HEAP8 is defined as an Int8Array, not a Uint8Array: var HEAP8 = new global.Int8Array(buffer); so it's not immediately obvious what the problem is, though I haven't dug into it to see what's really going on yet.

I think that we restricted (temporarily?) the possible load/store first argument to be an UInt8Array, for simplicity. This patch changes all load/store to take the Uint8Array as their first argument. It compiles, and then as the SIMD object is overwritten, there's a link error. Your turn again ;) I will look into allowing other array types again, but I think I am not recalling something silly that prevented us from doing it (or maybe this was needing the extra page after the mmapped region, that we eventually added as a workaround for the macos x handler issue).

I've now updated Emscripten to use HEAPU8 and fixed the link error and it now works! The code validates and runs correctly with SIMD code.

Here's the a.out.js file produced by Emscripten.

In addition to sse.expandfft.c, I've been able to compile and run C++ testcases using the auto-vectorization in LLVM in Emscripten too. So far, I've only been using float32x4, but the things that I have tried have all worked. This is a cool milestone. Congrats to everyone!