[llvm] r277972 - [SimplifyLibCalls] Emit sqrt intrinsic instead of a libcall.

[Davide Italiano via llvm-commits]

On Tue, Aug 9, 2016 at 12:48 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Mon, Aug 8, 2016 at 9:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> Hi Davide,
>>
>> I don't think this is correct. The problem is that, unlike most of our math intrinsics, our sqrt intrinsic has different semantics from the libc function. Specifically, our LangRef says:
>>
>> The ‘llvm.sqrt‘ intrinsics return the sqrt of the specified operand, returning the same value as the libm ‘sqrt‘ functions would. Unlike sqrt in libm, however, llvm.sqrt has undefined behavior for negative numbers other than -0.0 (which allows for better optimization, because there is no need to worry about errno being set). llvm.sqrt(-0.0) is defined to return -0.0 like IEEE sqrt.
>>
>> Now, under fast-math, we don't need to worry about -0.0, but we can't transform pow(x, 0.5) -> sqrt(x) using llvm.sqrt unless we know that x is non-negative. Otherwise, we've potentially added UB (where, before, we just had a NaN return value). The fast/nnan flags are not allowed to induce UB for NaNs, even if we don't define the resulting value. The LangRef says for nnan:
>>
>> No NaNs - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined.
>>
>> Thanks again,
>> Hal
>>
>
> Uh, thanks. I'll take a look at this today. Sorry.
>
> --
> Davide

Sorry, I was distracted by other things during the day. This should be
fixed in r278200. Thanks again for your review!

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare