BINARYEN_IMPRECISE, on or off by default?

[kripken]

wasm will trap on e.g. 1/0 in integers, but asm.js didn't. Binaryen's asm2wasm can compile code in two modes, "precise" which should behave exactly like before (and exactly like a native build), by avoiding traps carefully, and an "imprecise" mode which ignores that things might trap, which is faster (but might trap).

• Precise by default (current setting) means people aren't surprised by correctness bugs, but are surprised by perf issues.
• Imprecise by default would mean people are surprised by correctness bugs, but are not surprised by perf issues.
• A third option might be to try to get the precise mode up to the same speed as imprecise.

No obvious answer what is better here. Thoughts?

[dschuff]

Maybe it depends on exactly what sort of operations are included here aside from to division by 0. But "exactly like a native build" isn't really a thing; at least it's not just one thing: there is more than one native platform, and they have different behaviors (even different OSes on the same hardware can have different behavior). This is exactly why C has undefined behavior in the first place. For division by 0 (and other places where the standard has undefined behavior) I would say we should let it trap. In fact, for most cases I would really prefer trapping to some other behavior, but maybe that depends on the specifics. Of course this is slightly complicated by the fact that users may be migrating existing codebases from asm.js, so there's potential desire for compatibility; but again, we are talking about broken code, so I'd say it should be fine to have a compatibility option, but off by default.

But what other behaviors are affected byBINARYEN_IMPRECISE? (and what exactly is meant by "precise", anyway? To me, trapping seems more "precise" than some other behavior, in which you might not discover your bug until some random time further down the line, sort of like why sanitizers are useful in cases of memory safety bugs).

[juj]

Hmm, I find the terms "precise" and "imprecise" a bit confusing here. Does this only control the behavior of what happens on an integer div by zero and an integer modulus of zero? If so, could the option be something explicit like BINARYEN_INT_DIV0_THROWS=0/1 or similar?

How do we avoid traps? Manually by inserting if (divisor == 0) checks in the emitted code before each integer division?

[kripken]

Yeah, the term isn't the best I guess. The idea behind it was "precise = behave precisely the same as we always have and the way most native builds do".

Things affected:

• i32, i64 div and rem, signed and unsigned
• float-to-int truncation

This does affect real-world code, e.g. some things in the emscripten test suite, as well as the csmith fuzzer generates code that hits these.

We currently avoid traps by calling out into another function. I think right now that does an ffi into JS, which is easiest - we are guaranteed to get the same semantics as JS. Instead we could check for 0 or the float-to-int trunc limits and carefully do what JS would do, in wasm, which would be faster. Note that we don't and probably shouldn't do this inline because of code size concerns.

[juj]

I can think of the following build modes could be useful:

• abort: Abort execution on each integer div/mod by zero, and print a callstack where it occurs.
• fast: "I know my code will not do any bad div/mod by zeros, give me the fastest possible code, and if it happens to do a div/mod by zero, I don't care what ever happens (can abort or produce garbage or whatever)"
• quiet: If my code happens to do a div/mod by zero, under any circumstances don't abort execution, but generate an undefined result from that operation and keep on going. (garbage in, garbage out principle)
• strict: If my code does a div/mod by zero, throw me a C++ exception that I can try { } catch() and choose how to proceed. (c.f. on Windows SEH handling)

The first three sound like we can do, but not sure if wasm will have facilities (yet?) for the fourth strict mode.

Is the float-to-int truncation about float not being representable as an int? E.g. converting, say, 1e90 to an integer? Perhaps that could have a separate flag to control, but with the same modes as above?

[juj]

(Currently asm.js only has build mode quiet).

Generally div/mod by zeroes have generated 0 as result on asm.js, but can't recall if we actually strongly defined them that way?

[dschuff]

I'm not sure about float->int truncation; but I think for wasm div/rem, abort and fast are the same, and they are just equivalent to letting wasm trap (browsers will give you a callstack in any case there I think). I think quiet is the current "precise" behavior? We could maybe do strict with some support from the compiler; not sure how much work it would be or who would want benefit from it.

[dschuff]

@juj yes, trunc operations trap if the FP value is NaN or doesn't round to an integer in range: see https://github.com/WebAssembly/design/blob/master/Semantics.md#datatype-conversions-truncations-reinterpretations-promotions-and-demotions

[dschuff]

For that we could continue to thunk to JS, or probably just compile something from libm into wasm and call it before each trunc operation, which might (?) be faster. zero checks would probably be faster compiled into wasm if it's just making the result 0 when the dividend is 0.

I think the default should be to trap on zero dividends and truncation range errors, which would be the fastest, and probably would be what I'd want as a developer (since it gives you immediate feedback when you have the problem and tells you exactly where it is).

We could also have an asm.js compatibility mode, which would have zero-checks on divide and emulate whatever the asm.js behavior is for truncation. Depending on how much work we think that is, it might be worth finding out if anyone wants that; but if it's really simple then maybe it's easy just to do it.

[juj]

Perhaps strict might not be such a good term, but calling it throw might be better.

In that case I vote for having four build modes abort, fast, quiet, throw. It could be that fast ends up meaning the same as e.g. abort, but it's nice to have the developer be able to semantically say what they want, even though the result might be identical. That would retain a flexibility to future proof optimizations under the hood.

[juj]

As for the default, I think abort would be fine behavior. Then people can opt in to fast when they get to optimization land.

[dschuff]

If we are going do to anything beyond "do the fastest thing that is standards-compliant" or "get asm.js compatibility" then we are designing a debugging feature. If we are designing a debugging feature then we should give it some more thought about what exactly we want it to accomplish, the scope, the users and uses cases, etc. For example there's no reason it has to be limited to the arbitrary class of "things that just happen to be different between asm.js and wasm". We can also ask what other tools are available for the same purpose, and what other toolchain features we have that might be related, etc.

[kripken]

WebAssembly/binaryen#832 suggests we optimize our precise code, avoiding traps by checking for the conditions in a "safe" function in wasm that we call. This is a 3x improvement over the call out to JS we used to have, but still slow when the critical operations are done in a tight loop. Inlining might help, but it's tricky.

And on the other side of things, a project reported that they can't fix the traps - our recommended solution - because it's in third-party code for them that they don't want to maintain a fork of.

So I'm still not sure we have a good answer here. Precise mode will continue to be slow; imprecise mode requires people fix their source which in practice isn't always doable. This area remains one in which wasm is a regression compared to asm.js, sadly.

[juj]

I propose we give the following linker flags:

• -ffloat-to-int-overflow=abort: Lets the wasm trap exception from float to int conversion being out of range get thrown unhandled to JS. In our JS shell, we could catch these and print out a message "Use -ffloat-to-int-overflow=abort|clamp|fast to specify the desired behavior." to guide users to the option.
• -ffloat-to-int-overflow=clamp: Clamps out of bound values to INTMIN and INTMAX.
• -ffloat-to-int-overflow=fast: Don't care what the behavior is, just make float to int conversions run as fast as possible when overflows are assumed not to occur in the program.
• -fdiv-by-zero=abort: Lets the wasm trap exception from div by zero and remainder by zero get thrown unhandled to JS. In our JS shell, we could catch these and print out a message "Use -fdiv-by-zero=abort|quiet|fast to specify the desired behavior." to guide users to the option.
• -fdiv-by-zero=quiet: Div by zero and remainder by zero should not abort in any condition, but always keep on going, with undefined result from the computation.
• -fdiv-by-zero=fast: Don't care what the behavior is, just make float divisions and remainder ops run as fast as possible when div/mod by zero are assumed not to occur in the program.

Also, I believe we have a limitation that these flags can't be controlled at compilation unit level, but they always need to be specified for the final link, so we should make the compiler yell out and abort if these are being passed when not producing a final link (as opposed to silently ignoring them).

This kind of options set would allow nicely later expanding to throw modes where we'd throw a C++ exception, but no need to implement that now. As for defaults, it would be sensible to have -ffloat-to-int-overflow=clamp be a default, because that option is well defined (although also -ffloat-to-int-overflow=abort would also be a sensible default), and for div/mod by zeroes, -fdiv-by-zero=abort is good default, albeit noted that it's not the same behavior as with asm.js. I don't think we need to follow the same defaults that asm.js had, especially when it will be easy and explicit to guide users to which flags to set if they want to have the asm.js behavior. The issue #3836 was about adding this option for debugging earlier, so the old asm.js behavior wasn't too good as a default I think.

[dschuff]

So for wasm, I guess fast is the same as abort (since wasm traps in both of these cases), and for asm.js there would be extra code? What's the current behavior on asm.js for float->int overflow?