<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/30/2012 10:28 PM, Michael Ilseman
wrote:<br>
</div>
<blockquote
cite="mid:33104530-0B16-43D4-ABF7-3E265C89414C@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<div>
<div>On Oct 30, 2012, at 4:19 PM, Dan Gohman <<a
moz-do-not-send="true" 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 2:25 PM, Michael
Ilseman <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
no signed zeros (S)<br>
- The optimizer is allowed to not distinguish between -0
and +0 for the<br>
purposes of optimizations.<br>
</blockquote>
<div><br>
</div>
<div>Ok, I checked LLVM CodeGen's
existing -enable-no-infs-fp-math
and -enable-no-nans-fp-math flags, and GCC's
-ffinite-math-only flag, and they all say they apply to
results as well as arguments. Do you have a good reason
for varying from existing practice here?</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The primary example I was trying to simplify with that
change was x * 0 ==> 0. It can be performed if you assume
NIS inputs, or NS inputs and N outputs. This is because Inf *
0 is NaN. In hindsight, this is all making things more
confusing, so I think I'll go back to "arguments and results"
and allow this optimization for NS. GCC gets around this by
lumping Inf and NaN under the same command line option.</div>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div>Phrasing these from the perspective of the optimizer is
a little confusing here. </div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it might be clearer to change "The optimizer is
allowed to …" to "Allow optimizations to …" and clean up the
wording a bit.</div>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div>Also, "The optimizer is allowed to [not care about X]"
read literally means that the semantics for X are
unconstrained, which would be Undefined Behavior. For I
and N here you have a second sentence which says only the
result is undefined, but for S you don't. </div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>'S' shouldn't have any undefined behavior, it just allows
optimizations to not distinguish between +/-0. <span
style="background-color: rgb(255, 255, 255); font-family:
arial, sans-serif; font-size: 13px; ">It's perfectly legal
for the operation to receive a negative zero, the
operation just might treat it exactly the same as a
positive zero. I would rather have that than undefined
behavior.</span></div>
</div>
</div>
</blockquote>
<br>
I'm not an expert in writing specifications, but I think defining
the S flag in this manner would be preferable:<br>
no signed zeros (S) - If present, then the result of a floating
point operation with -0.0 or +0.0 as an operand is either the result
of the operation with the original specified values or the result of
the operation with the +0.0 or -0.0 replaced with its opposite sign.<br>
<br>
As a side note, it's never explicitly stated in the language
reference how much of IEEE 754 semantics floating point operations
must follow.<br>
<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
News submodule owner
DXR coauthor</pre>
</body>
</html>