[llvm-dev] Safe fptoui/fptosi casts

[Nikita Popov via llvm-dev]

On Mon, Nov 5, 2018 at 11:41 PM Thomas Lively <tlively at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181119/8f857dea/attachment.html>