bad result for powi inside some immutable types

[JeffBezanson]

julia> foo(n) = (1.0^n, 2.0^n, 3.0^n)
foo (generic function with 1 method)

julia> foo(2)
(9.0,9.0,NaN)

[JeffBezanson]

See fa315c9#commitcomment-5987511

[Keno]

Ok, I'm fairly sure the issue is in the return from the function and it does seem like an llvm bug to me. Haven't yet been able to replicate it in lli though.

[vtjnash]

perhaps the llvm vectorizor expects power-of-two-length vectors?

[cmundi]

f5(n) = (1.0^n, 2.0^n, 3.0^n, 4.0^n, 5.0^n)
f6(n) = (1.0^n, 2.0^n, 3.0^n, 4.0^n, 5.0^n, 6.0^n)
Both work as expected. The LLVM IR for f2, f3, f4, f5, f6 all look correct (casual inspection). Ihave not looked but I suspect a backend codegen optimization has gone amok for the special case of three return values. Just guessing.

[Keno]

Reported as http://llvm.org/bugs/show_bug.cgi?id=19530

[JeffBezanson]

We will have to work around this. I propose recognizing small constants (2 and 3) in our powi_llvm intrinsic and converting them to multiplies, falling back on calling libm pow.

[Keno]

I'm tracking down the upstream issue here. Looks to be in DAG legelization. Before:

After:

[Keno]

Upstream patch is at http://reviews.llvm.org/D4968.

[quinnj]

What is that sorcery??

[Keno]

Committed as http://reviews.llvm.org/rL216117.

[staticfloat]

No wonder Keno wanted GraphViz fixed. ;)