<div dir="ltr">On 2 March 2018 at 06:32, Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>> Potentially controversial points:<br>><br>>  - Because LLVM reorders and speculates the instruction forms, and because<br>> IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is<br>> clear that SNaNs are outside of the domain of these LLVM operations.  Either<br>> speculation is ok or trapping on SNaN is ok, pick one…  (and we already did<br>> :)<br><br>Whether operations on sNaNs trap in the "default execution environment", or otherwise interrupt normal control flow or have side effects, seems to be the key point of disagreement here. I don't believe they do, at least as far as my amateur reading of IEEE 754-2008 can tell:<br><br>1) (most) operations on sNaN signal an _invalid operation_ exception (§7.2), and so do many other operations on other values (also §7.2), such as: 0 * inf, inf / inf, fma(0, inf, x), sqrt on negative inputs, converting a float to an integer when the source is NaN/is infinity/does not fit in the destination type, etc.<br>2) IEEE specifies a default way of handling exceptions (§7.1), which for _invalid operation_ is returning a quiet NaN (§7.2).<br>3) Language standards should offer a way to override the default exception handling (§8.1).<br>4) _Immediate_ alternate exception handling (§8.3) can be implemented via traps (§8.3, NOTE 2).<br><br>As I said I'm not an expert on this standard, but it seems very clear-cut to me that IEEE specifies operations like divide(x, sNaN) should return a quiet NaN, nothing else, unless the program uses language-provided facilities to install some other behavior. In this respect sNaN operations are not any different from other invalid, inexact, overflowing, etc. operations (as Steve already said).<br><br>If this is the case, there is no reason to treat e.g. "fdiv %x, snan" as having side effects or some sort of UB: fdiv and friends already assume a "default" fenv where nobody looks at flags, changes rounding modes, installs alternative exception handling, etc. so the invalid operation exception from sNaN operands is just as irrelevant as all the other exceptions are. LLVM can simply assume the default exception handling (as it already does in many cases) and fold calculations on signaling NaNs to quiet NaNs if it so wishes.<br><br>I have not surveyed the numerous hardware implementations (and everything else that goes into the "default execution environment", e.g., what the OS does), so it might be that some of those default to trapping on sNaNs. I've never heard of such a thing, and just verified that it does not happen on my x86_64 machine, but there's a lot of weirdness out there. If you know of any targets that trap on sNaN by default, please tell us. Otherwise, going only by IEEE (as you yourself did), I don't see how traps could be a possibility without the program opting into fenv access (in which case the frontend has to emit constrained intrinsics anyway).<br><br>Cheers,<br>Robin</div>