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

Davide Italiano via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 9 12:48:32 PDT 2016


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


More information about the llvm-commits mailing list