[llvm-dev] Safe fptoui/fptosi casts

[Nikita Popov via llvm-dev]

On Mon, Nov 19, 2018 at 1:02 PM Nikita Popov <nikita.ppv at gmail.com> wrote:

> 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
>

Forgot to post this earlier, I've created https://reviews.llvm.org/D54749
with the first step towards supporting saturating float-to-int casts,
including new intrinsics and baseline DAG expansion (which generates
horrible code on X86). Would appreciate if someone could take a look :)

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181212/2239106a/attachment.html>