search for: formatharddr

...s are not defined on SNaNs, SNaNs are outside of their domain, and thus the LLVM instructions are undefined on these inputs. As such, it would be perfectly reasonable to “constant fold” an "fadd SNaN, 42” instruction into unreachable and delete all the code after it, or turn it into a call to formatHardDrive(). [2] - Because an ‘undef’ operand can be an arbitrary bit pattern representable by the type, and because the f32/f64 etc *types* can represent SNaNs, it is within the right of the compiler to constant fold “fadd undef, 42” into unreachable. QED. Summary and Recommendation: I don’t see an...

So you don’t think sNaNs can just be treated as if they were qNaNs? I understand why we would want to ignore the signaling part of things, but the rules for operating on NaNs are pretty clear and reasonable to implement. The signaling aspect can, I think, be safely ignored when we are in the mode of assuming the default FP environment. As for the distinction between IEEE and LLVM IR, I would