<div dir="ltr">Tim,<div class="gmail_extra"><br><div class="gmail_quote">2014-06-10 19:01 GMT+08:00 Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I think now I understand this a little bit. Following LLVM IR spec, when<br>
> using -ffast-math, -menable-no-nans are -menable-unsafe-fp-math enabled, and<br>
> this sounds reasonable to retain defined/stable/safe behavior, so we can't<br>
> return NaN, then 0.0 is a choice.<br>
<br>
</div>I think we probably *could* return a NaN, other phases would just be<br>
perfectly entitled to assume we hadn't. Which makes it a not<br>
particularly useful thing to return.<br>
<br>
0.0 probably isn't too bad either though; the advantage of "undef" is<br>
that it looks dodgy when scanning through IR so might make tracking<br>
down bugs easier.<br></blockquote><div><br></div><div>If the "undef" you are talking about is the one in LLVM IR, I think it is not OK, because undef means an undefined value, and for well-defined program, this undef shouldn't affect semantic. But for the case like sqrt(-2.01), the original C code is trying to use NaN, which is defined value (if we ignore errono) to indicate the number is invalid state. For example, for LLVM IR undef, if we change it to be fixed number (e.g. 0) for shuffle vector mask, the program logic should retain the same, but for the case of using sqrt(-2.01) to define NaN in C, we can't change it to be a fixed number, and the program would fail otherwise.</div>
<div><br></div><div>Anyway, I see a lot of discussions on internet saying fast-math implies no checks for NaN, If users' code logic depends on NaN, fast-math should just not work.</div><div><br></div><div>Another interesting finding is gcc aarc64 and gcc x86 behave differently for -ffast-math. For gcc x86, fp zero is being used, but gcc aarch64 is either keeping sqrt lib call or using sqrt instruction. I would say gcc aarch64 behaves unexpectedly, but I couldn't simply say it is incorrect for fast-math. Or maybe the fp zero return for sqrt(-2.01) came from gcc x86 behavior originally?</div>
<div><br></div><div>Thanks,</div><div>-Jiangning </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>