WASM: floating-point-to-integer conversion error in latest incoming branch

[Floh]

Hi,

I just updated to the latest emscripten incoming branch to and noticed a regression in 2 of my Oryol samples that use the Bullet physics library.

The clang-fastcomp git repo version is:

commit 8e81642c66d82eb956ce2832a2f2f69adee48e55

Date:   Tue May 29 15:51:28 2018 -0700

And the emscripten git repo is on:

commit b5313f6504c6b34f283fbd2d3a1d18561d0e9fce

Date: Date:   Fri Jun 1 19:44:12 2018 -0400

I'm not sure since when the problem was happening, but it must have been introduced during the last 2 weeks or so (see below).

Go here: http://floooh.github.io/oryol-sticky-tests/BulletPhysicsBasic.html (NOTE: you need to disable uBlock Origin since that blocks .wasm blobs from github.io)

Note the error message in the JS console, on Chrome this is:

BulletPhysicsBasic.html:101 exception thrown: RuntimeError: float unrepresentable in integer range,RuntimeError: float unrepresentable in integer range

...

BulletPhysicsBasic.js:1 Uncaught RuntimeError: float unrepresentable in integer range

...

And in FF:

exception thrown: RuntimeError: integer overflow,wasm-function[808]@http://floooh.github.io/oryol-sticky-tests/BulletPhysicsBasic.js:585500:1

...

RuntimeError: integer overflow

...

Anybody else seeing this with his code? Unfortunately it will be hard to create a reduced test case, the problem doesn't happen in any of my simpler demos, only in the Bullet Physics demos. 

It does not happen with an older version of the emscripten SDK here: http://floooh.github.io/oryol-samples/wasm/BulletPhysicsBasic.html (this was last uploaded on May-10, and I guess the emscripten SDK was also from around that time).

[Alon Zakai]

Possible this is a wasm trap issue, see

https://kripken.github.io/emscripten-site/docs/compiling/WebAssembly.html#trap-mode

Basically, wasm will trap on some operations that asm.js will not, and the tricky thing is that when that happens depends on the optimizer. So the recent LLVM update may have caused that on a codebase that worked before.

In general the fix is just to do

-s "BINARYEN_TRAP_MODE='clamp'"

that causes a slight increase in code size, but should have little downside. wasm may fix this in the spec eventually.

We did debate at length which mode should be the default, and maybe it should have been "clamp". We can still revisit that I guess.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

Alright, trap-mode clamp fixes the problem :) I've switched this on by default in my build system for now.

Size increase is somewhere between 1% and 5% uncompressed size. 1% is ok, 5% is a bit on the heavy side... I guess I'll need to think about whether I want to keep this enabled as default :)

These are the previous sizes, all uncompressed:

635953 BulletPhysicsBasic.wasm

664502 BulletPhysicsCloth.wasm

478597 Dragons.wasm

403451 DrawCallExplorer.wasm

396876 Fractal.wasm

645838 ImGuiDemo.wasm

707736 KC85-3.wasm

499797 MeshViewer.wasm

369588 NuklearUIAdvanced.wasm

380985 NuklearUIBasic.wasm

509353 OrbViewer.wasm

254060 Paclone.wasm

739777 SoloudMOD.wasm

471813 SoloudTedSid.wasm

390492 SoundTest.wasm

182635 StbVoxelDemo.wasm

694173 TurboBadgerDemo.wasm

And the new sizes with trap-mode clamp:

642468 BulletPhysicsBasic.wasm

671126 BulletPhysicsCloth.wasm

497417 Dragons.wasm

424451 DrawCallExplorer.wasm

414758 Fractal.wasm

682760 ImGuiDemo.wasm

712697 KC85-3.wasm

526581 MeshViewer.wasm

375916 NuklearUIAdvanced.wasm

391724 NuklearUIBasic.wasm

530599 OrbViewer.wasm

255468 Paclone.wasm

762573 SoloudMOD.wasm

495356 SoloudTedSid.wasm

410622 SoundTest.wasm

183756 StbVoxelDemo.wasm

702113 TurboBadgerDemo.wasm

Cheers and thanks for pointing me in the right direction :)

-Floh.

[Alon Zakai]

Thanks for the size data. 5% is disturbing, we should look more into that.

One relevant thing is the optimization level. Is this in -O3? In that case, it may inline the clamp functions in many places.

We've considered splitting up clamp into options for clamping of specific operations, but the size difference has tended to be small (0.5% on bullet, for example) so it was never a priority. But if we're seeing 5% on real-world code, and not due to -O3, we may need to do something fast.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Floh]

Yes, this is with -O3 and "--llvm-lto 1", so it's most likely inlining.

Can you point me to the clamp function code? Would be good to know how much overhead I just added ;)

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

Sure, here's f32-to-int:

https://github.com/WebAssembly/binaryen/blob/master/test/passes/trap-mode-clamp.txt#L101

Basically it checks for NaNs, then if it's too low or too high for an int32.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.