LLVM intrinsic unimplemented: llvm.uadd.with.overflow about emscripten

[kripken]

It should indeed be simple to add. However, these instructions are meant to be very fast (implemented using native CPU instructions dedicated to them), and emulating them in JS will be very slow. So I am curious what optimization generates them, perhaps the best thing is to avoid it somehow.

[max99x]

I haven't looked into it, but I'm guessing it won't be generated unless the overflow is significant, in which case doing it the fast way will simply produce incorrect code, and the unoptimized version might be doing the same extra operations as we'd be doing by implementing it.

[kripken]

I agree. But my question is then, how does one write C/C++ code that actually cares about overflows? The C/C++ standards were very careful to not allow such things to be detected directly. Are these compiler-specific extensions perhaps? The only alternative I can think of is that the compiler detects code that manually checks for overflows, like

void func(char x) {
  x++;
  if (x == 0) printf("overflow!");
}

and optimizes that, which seems unlikely but possible. Would be simple to just tell the compiler to not perform that optimization though, since it won't help us here (in fact it will hurt).

[max99x]

This is - again - a total guess on my part, but it might be translating int64_t additions into two manual int32_t additions with carry/overflow correction on a 32-bit machine - unoptimized is a straightforward implementation while optimized is one with intrinsics.

[kripken]

Hmm, that could be. If so, it sounds like specialization for a very specific architecture (one that doesn't have 64-bit math ops) so hopefully something we can avoid. (Also, we should try to avoid 64-bit math anyhow because it's a poor fit for JavaScript's native types.)

No harm in implementing this stuff, though.

[kripken]

We added support for this (but it can't be fast...)

[kripken]

We should now have all the overflow add/mul intrinsics on incoming.