<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op do 10 okt. 2019 om 18:39 schreef Ulrich Weigand via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<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><p><tt><font size="2">Kevin Neal <<a href="mailto:Kevin.Neal@sas.com" target="_blank">Kevin.Neal@sas.com</a>> wrote on 01.10.2019 16:25:55:<br><br>> Ulrich offered to do it instead since I expect he can get it done <br>> much faster than me. Instead I'm doing SIToFP and UIToFP. Ulrich <br>> said he wasn't going to be able to get to it for a couple of weeks, <br>> but that was a week or two ago. <br></font></tt><br><tt><font size="2">Sorry for the late reply, I've been traveling ...</font></tt><br><br><tt><font size="2">Yes, I'll start looking into strict FP comparisons.  One issue is</font></tt><br><tt><font size="2">indeed that we'll need to support both signaling and non-signaling</font></tt><br><tt><font size="2">comparisons.</font></tt><br><br><tt><font size="2">My prefered solution would probably be to have two sets of strict</font></tt><br><tt><font size="2">intrinsics, one for signaling compares and one for non-signaling</font></tt><br><tt><font size="2">ones, implement those in the back-ends using the appropriate set</font></tt><br><tt><font size="2">of signaling vs. non-signaling instructions, and then leave it to</font></tt><br><tt><font size="2">the front-end to chose which of the two to use when, in order to</font></tt><br><tt><font size="2">implement the semantics mandated by the language standard.</font></tt><br><br></p></div></blockquote><div>Thanks for sharing your thoughts, Ulrich. The approach described above seems to make sense to me. </div></div></div>