[RFC] Use saturated float to int casts by default

[MaxGraey]

standardized proposal

f64.MAX_VALUE as u64 -> 18446744073709551615
f64.MAX_VALUE as i64 -> 9223372036854775807
NaN as i64 -> 0

For small types it will be emulated:
f32.MAX_VALUE as u8 -> 255

currently we have traps in all this cases. For saving this behaviour we could use unchecked:
unchecked(f64.MAX_VALUE as u64) -> panic

[dcodeIO]

Wondering if saturation is too surprising as a default, as it neither indicates a problem nor behaves like JS would. Not an easy call to make, with one alternative being Binaryen's trapMode=js, doing about what we want (for non-SMIs), but adding quite some code on conversions.

[dcodeIO]

A more JS-y take might be to add conversion functions to the wrappers, like F64#toU64 etc. and call these behind the scenes on conversions, emulating JS behavior. Binaryen will most likely inline these when optimizing, and may be able to optimize them away when dealing with contant values. Wdyt?

[MaxGraey]

JS wrapping conventions is even more surprising but actuallly make sense when you have only numbers and small integers. Also it pretty expensive. Current trapping during float to int also very surprising btw. But less surprising than UB like in C++. Saturation convention is best solution I think in many ways.

Also we could add global compiler flag. Actually it already exists - --trapMode

[dcodeIO]

Btw, is this equivalent to trapMode=clamp?

[MaxGraey]

Btw, is this equivalent to trapMode=clamp?

yes.

[dcodeIO]

I see. Does Binaryen already use the _sat instructions if the respective feature is enabled?

[MaxGraey]

I see. Does Binaryen already use the _sat instructions if the respective feature is enabled?

I don't know. But I guess we should use own conversion. Due to in binaryen this do not optimal. Also we anyway will do this for f64->i16, f32->u8 and etc

[dcodeIO]

So let's play this through and pretend we'd go for clamping by default, then we'd require Non-trapping float-to-int conversions to be enabled by default or provide a polyfill where it isn't, i.e., Safari, to provide consistent behavior. That's about what you are proposing?

[MaxGraey]

perf costs for saturation conv vs UB
https://godbolt.org/z/7n8rbc

For WerAssembly it shouldn't affect due to trapping i32.trunc_u/f64 command also required bounds checking on VM side.