Hi Micheal,<br><br>On Mon, Oct 29, 2012 at 4:34 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I<br>
Flags<br>
---<br>
no NaNs (N)<br>
- ignore the existence of NaNs when convenient<br>
no Infs (I)<br>
- ignore the existence of Infs when convenient<br>
no signed zeros (S)<br>
- ignore the existence of negative zero when convenient<br></blockquote><div><br>Does this mean ignore the possibility of NaNs as operands, as results, or both? Ditto for infinity and negative zero.<br><br>Also, what does "ignore" mean? As worded, it seems to imply Undefined Behavior if the value is encountered. Is that intended?<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
allow fusion (F)<br>
- fuse FP operations when convenient, despite possible differences in rounding<br>
(e.g. form FMAs)<br></blockquote><div><br>What do you intend to be the relationship between this and @llvm.fmuladd? It's not clear whether you're trying to replace it or trying to set up an alternative for different use cases.<br>
<br>Is your wording of "fusing" intended to imply fusing with infinite intermediate precision only, or is mere increased precision also valid?<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">
unsafe algebra (A)<br>
- allow for algebraically equivalent transformations that may dramatically<br>
change results in floating point. (e.g. reassociation)<br></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">
Not all combinations make sense (e.g. 'A' pretty much implies all other flags).<br>
<br>
Basically, I have the below semilattice of sensible relations:<br>
A > S > I > N<br>
A > F<br>
Meaning that 'A' implies all the others, 'S' implies 'I' and 'N', etc.<br></blockquote><div><br>Why does it make sense for S to imply I and N? GCC's -fno-signed-zeros flag doesn't seem to imply -ffinite-math-only, among other things. The concept of negative zero isn't inherently linked with the concepts of infinity or NaN.<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">
<br>
It might make sense to change the S, I, and N options to be some kind of finite<br>
option with levels 3, 2, and 1 respectively. F and A could be kept distinct. It<br>
is still the case that A would imply pretty much everything else.<br>
<br>
N - no NaNs<br>
x == x ==> true<br></blockquote><div><br>This is not true if x is infinity.<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">
<br>
S - no signed zeros<br>
x - 0 ==> x<br>
0 - (x - y) ==> y - x<br>
<br>
NS - no signed zeros AND no NaNs<br>
x * 0 ==> 0<br>
<br>
NI - no infs AND no NaNs<br>
x - x ==> 0<br>
Inf > x ==> true<br></blockquote><div><br>With the I flag, would the infinity as an operand make this undefined?<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
A - unsafe-algebra<br>
Reassociation<br>
(x + C1) + C2 ==> x + (C1 + C2)<br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Redistribution<br>
(x * C) + x ==> x * (C+1)<br>
(x * C) + (x + x) ==> x * (C + 2)<br>
Reciprocal<br>
x / C ==> x * (1/C)<br>
<br>
These examples apply when the new constants are permitted, e.g. not denormal,<br>
and all the instructions involved have the needed flags.<br></blockquote><div><br>I'm confused. In other places, you seem to apply that reassociation would be valid even on non-constant values. It's not clear whether you meant to contradict that here.<br>
<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">
-fp-contract=<value><br>
I'm not too familiar with this option, but I recommend that 'all' turn on the<br>
'F' bit for all FP instructinos, default do so when following the pragma, and<br>
off never doing so. This option should still be passed to the backend.<br></blockquote><div><br>Please coordinate with Lang and others who have already done a fair amount of work on FP_CONTRACT.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(Optional)<br>
I propose adding the below flags:<br>
<br>
-ffinite-math-only<br>
Allow optimizations to assume that floating point arguments and results are<br>
NaNs or +/-Inf. This may produce incorrect results, and so should be used with<br>
care.<br>
<br>
This would set the 'I' and 'N' bits on all generated floating point instructions.<br>
<br>
-fno-signed-zeros<br>
Allow optimizations to ignore the signedness of zero. This may produce<br>
incorrect results, and so should be used with care.<br>
<br>
This would set the 'S' bit on all FP instructions.<br></blockquote><div><br>These are established flags in GCC. Do you know if there are any semantic differences between your proposed semantics and the semantics of these flags in GCC? If so, it would be good to either change to match them, or document the differences.<br>
<br>Dan<br><br></div></div>