<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 1, 2012, at 3:08 PM, Dan Gohman <<a href="mailto:dan433584@gmail.com">dan433584@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<div><div>This is similar to how gcc defines <b style="font-size:13px;font-family:arial,sans-serif">-fno-signed-zeros:</b></div><div><span style="font-size:13px;font-family:arial,sans-serif">"Allow optimizations for floating point arithmetic that ignore the signedness of zero. </span><small style="font-family:arial,sans-serif">IEEE</small><span style="font-size:13px;font-family:arial,sans-serif"> arithmetic specifies the behavior of distinct +0.0 and -0.0 values, which then prohibits simplification of expressions such as x+0.0 or 0.0*x (even with </span><b style="font-size:13px;font-family:arial,sans-serif">-ffinite-math-only</b><span style="font-size:13px;font-family:arial,sans-serif">). This option implies that the sign of a zero result isn't significant."</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">I'll revise my description to also mention that the sign of a zero result isn't significant. </span></div>
</div></div></blockquote><div><br>Ok, I see what you're saying here now.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Also, even when you do have the second sentence, it seems to contradict the first sentence.</div>
<div><br></div></div></blockquote><div><br></div></div><div>Why does it contradict the first sentence? I meant it as a clarification or reinforcement of the first, not a contradiction.</div></div></div></blockquote><div>
<br>Suppose I'm writing a backend for a target which has an instruction that traps on any kind of NaN. Assuming I care about NaNs, I can't use such an instruction for regular floating-point operations. However, would it be ok to use it when the N flag is set?<br>
<br>If the "optimizer" may truly ignore the possibility of NaNs under the N flag, this would seem to be ok. However, a trap is outside the boundaries of "undefined result". So, which half is right?<br>
<br></div></div></blockquote><div><br></div><div>That makes sense, I was thinking of things only in terms of the optimizer and not in terms of instruction selection. Which do you think is better, Undefined Behavior or that instruction selection should disregard those bits? I'd lean towards undefined behavior, but I don't have a good feel for LLVM's overall design for undefined behavior, poison values, etc.</div><br><blockquote type="cite"><div class="gmail_quote"><div>Dan<br><br></div></div>
</blockquote></div><br></body></html>