emcc does not lower too-large vector types

[allanlw]

Consider the following program:

#include <stdio.h>

#define vs 4
#define vt double

typedef vt myvector __attribute__ ((vector_size (sizeof(vt) * vs)));

int main() {
  myvector a = {0}, b = {0};
  for (int i = 0; i < vs; i++) { a[i] = i; b[i] = i; }

  a *= b;

  for (int i = 0; i < vs; i++) {
    printf("%f\n", a[i]);
  }
}

emcc fails to compile this with an unexplained assertion error: LLVM ERROR: VT->getBitWidth() <= 128, but clang and GCC handle it fine. The solution is to lower the too-large SIMD types until they are of supported width.

[juj]

Yeah, this is a current limitation, we don't split up too large SIMD operations to smaller ones. I wonder if LLVM might have some kind of automated higher level machinery to do that. Note that SIMD.js doesn't have a double * 2 type ("SIMD.Float64x2") even, so vs=2, vt=double is not expected to work here either, although for Emscripten purposes we use an unofficial polyfill for that, and Firefox has an unofficial implementation for that type in Nightly.

[juj]

For reference, here's a starting trail to the conversations about Float64x2 not getting in, tc39/ecmascript_simd#229 . That type was postponed to a "phase 2" implementation, the summary being that there were no presented cases to provide measurable speedups.

[allanlw]

In my specific case I don't care about SIMD speedups per-se, I care about compiling an existing codebase that uses vectors that are too large and expects the compiler to lower them.

My impression is that LLVM normally does this through TargetLowering but that emscripten skips the SelectionDAG stuff altogether, so this machinery can't be reused. Doing this through an opt pass might not be too bad, to lower into, say an array of vectors, although some care would need to be taken to implement gather and scatter and to make sure that a later pass does not re-vectorize. Perhaps for the more complex vector intrinsics, it might be easier to not replace them inline and instead call out to a polyfill function.

I might take a crack at writing such an opt pass if I ever get some free time.

[dschuff]

LLVM does normally handle this via target-independent SelectionDAG code, and you are correct that skipping that is the reason that fastcomp doesn't support this functionality. It could be done via an LLVM IR pass (the way the rest of the type "lowering" is done in fastcomp); my guess is that it's straightforward in principle but tricky in practice. When WebAssembly gets SIMD support (which we expect to have essentially the same functionality as the SIMD.js spec) the upstream wasm backend should support it via the conventional mechanisms. In fact there's a bit of proto-SIMD support there already which needs fleshing out (obviously it also needs an implementation in a wasm engine which isn't exposed yet either).

…

On Tue, Dec 13, 2016 at 6:19 AM Allan Wirth ***@***.***> wrote: In my specific case I don't care about SIMD speedups per-se, I care about compiling an existing codebase that uses vectors that are too large and expects the compiler to lower them. My impression is that LLVM normally does this through TargetLowering but that emscripten skips the SelectionDAG stuff altogether, so this machinery can't be reused. Doing this through an opt pass might not be too bad, to lower into, say an array of vectors, although some care would need to be taken to implement gather and scatter and to make sure that a later pass does not re-vectorize. Perhaps for the more complex vector intrinsics, it might be easier to not replace them inline and instead call out to a polyfill function. I might take a crack at writing such an opt pass if I ever get some free time. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4789 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEiKJc7rPcxy2HS1CncQZXjHH96glwXks5rHql0gaJpZM4LKHH9> .

[DiamondLovesYou]

I did this work years ago for PNaCl: https://codereview.chromium.org/1423873002. Sadly it never got merged, but it should still work for this.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.