Use 3 modes for potentially trapping ops in asm2wasm

[kripken]

• allow (just emit a potentially trapping op)
• js (do exactly what js does, even if it takes a slow ffi to do it)
• clamp (avoid the trap by clamping as necessary)

See emscripten-core/emscripten#4625

[sunfishcode]

This looks good to me. Obviously we could micro-optimize some things more if we really wanted, and the choice of what mode to have by default depends on how one weights various criteria, but what's here is a reasonable step forward.

[dschuff]

I'm on board with this general idea too. A few comments, and questions to make sure I understand right:

1. It looks like this mode applies to both float->int and div/rem (I'm happy with that, although if there were some good reason to have separate flags/modes, I'd be ok with that in this tool too since it's not an emscripten-user-facing tool).
2. As a nit, names like potentialTrapMode/potentiallyTrappingFoo seem unnecessarily verbose; I think the "potential" part goes without saying (we already have an op that always traps :) ) trappingOpMode (or even just trapMode) and trappingDiv/trappingConversion etc seem more readable.
   but yeah in general this looks good to me too.

[dschuff]

Actually also just so I understand. It looks like the clamp and JS mode for div/rem do the same thing now? Just return 0?

[kripken]

1. Yeah, this applies to both. We may split them up eventually, but actually I am thinking that is less likely, since we now have very fast non-trapping i32 operations (no ffis).
2. Maybe a little verbose, I agree. We already had makePotentiallyTrappingI32Binary etc., and it seems hard to shorten that (I think we discussed makeUnsafe* at some point, but not clear enough, and makeTrapping* is not accurate), so PotentialTrapMode seems consistent with that.
3. Yeah, clamp and JS mode do the same for int div/rem, both "clamp" div/rem of 0 to 0, the JS default here is good.

[dschuff]

Actually I think makeTrapping* is accurate. Just because something is "trapping" doesn't mean it necessarily always traps, just that it may trap.

[kripken]

Ok, not my first intuition but I can see how that works too, and shorter is nicer.

[dschuff]

This behavior is fine for now; I'd be very interested in seeing how wasm build of __fixsfsi or __fixdfdi compares with FFI+JS version.

[kripken]

Yeah, worth trying that.

[kripken]

Ok, how does this look now with the shorter names?