<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 1:02 PM Nikita Popov <<a href="mailto:nikita.ppv@gmail.com" target="_blank">nikita.ppv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 11:41 PM Thomas Lively <<a href="mailto:tlively@google.com" target="_blank">tlively@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>Here is how various languages behave with unrepresentable float-to-int casts:<br></div><div><br></div><div>Undefined Behavior: C, C++, D, Rust (unintentionally)<br>Implementation-Defined Behavior: C#, Go<br>Runtime Error: Swift, Julia<br>Saturation: Java, Rust (planned)<br>Modular Reduction: JavaScript, PHP</div><div><br></div><div>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.</div><div><br></div><div>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).<br></div><div><br></div><div>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 <a href="https://reviews.llvm.org/D54696" target="_blank">https://reviews.llvm.org/D54696</a>. 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.</div><div><br></div><div>Regards,</div><div>Nikita<br></div></div></div></div></div></blockquote><div><br></div><div>Forgot to post this earlier, I've created <a href="https://reviews.llvm.org/D54749" target="_blank">https://reviews.llvm.org/D54749</a> 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 :)<br></div><div><br></div><div>Regards,<br></div><div>Nikita<br></div></div></div></div>