(original) (raw)

On Mon, Nov 5, 2018 at 11:41 PM Thomas Lively <tlively@google.com> wrote:

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int\_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice to get rid of the wasm-specific intrinsic for behavior (2) and replace it with a target-independent intrinsic or IR, since this behavior is not actually particular to WebAssembly.

Here is how various languages behave with unrepresentable float-to-int casts:

Undefined Behavior: C, C++, D, Rust (unintentionally)
Implementation-Defined Behavior: C#, Go
Runtime Error: Swift, Julia
Saturation: Java, Rust (planned)
Modular Reduction: JavaScript, PHP

There are some caveats here (often there is more than one way to do the conversion, etc), but I think this gives the general idea.

The "Undefined Behavior" category is covered by the existing fptosi/fptoui instructions. Based on the responses, I understand that having a flag for "Implementation-Defined Behavior" is not well received (and I guess using platform intrinsics would be an alternative here).

To support the saturation behavior, I have been working on a pair of llvm.fptosi.sat / llvm.fptoui.sat intrinsics. My current implementation can be found at https://reviews.llvm.org/D54696. I'll work on splitting this up into more reviewable parts, though if there's any early feedback on the implementation approach, I'd appreciate that.

Regards,

Nikita