<html><body><p><tt><font size="2">Kevin Neal <Kevin.Neal@sas.com> 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><tt><font size="2">(Note that for the default LLVM compare IR instructions, those</font></tt><br><tt><font size="2">-like all floating-point instructions- are considered to only</font></tt><br><tt><font size="2">be used in contexts where FP exceptions are ignored, and therefore</font></tt><br><tt><font size="2">the signaling vs. non-signaling distinction is meaningless for</font></tt><br><tt><font size="2">those IR instructions.)</font></tt><br><br><tt><font size="2">Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><BR>
</body></html>