[llvm-dev] Safe fptoui/fptosi casts (original) (raw)

Nikita Popov via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 12 05:07:31 PST 2018

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>

More information about the llvm-dev mailing list