Code generation failure on expression involving Tuples of length > 2 (regression in 0.4-dev)

[samuelpowell]

The following works as expected:

stup = (-6.3, 100.3)
stupfloor(tup::Tuple) = floor(tup[1]), floor(tup[2])
stupfloor(stup)

(-7.0,100.0)

However increasing the length of the tuple beyond two elements results in abnormal behaviour:

ltup = (-6.3, 100.3, -6.8, 19.6)
ltupfloor(tup::Tuple) = floor(tup[1]), floor(tup[2]), floor(tup[3]), floor(tup[4])
ltupfloor(ltup)

(19.0,6.500476771537064e252,NaN,NaN)

Evaluating in the global scope works correctly:

floor(tup[1]), floor(tup[2]), floor(tup[3]), floor(tup[4])

(-7.0,100.0,-7.0,19.0)

In the failing cases, Julia appears simply to move some data around to jump somewhere:

    .text
Filename: In[2]
Source line: 2
    pushq   %rbp
    movq    %rsp, %rbp
Source line: 2
`   movsd   24(%rdi), %xmm0
    movabsq $139740990100656, %rax  # imm = 0x7F17FC1354B0
    popq    %rbp
    jmpq    *%rax

Everything works correctly under 0.3.9.

I have encountered this error on the following builds of 0.4-dev

Julia Version 0.4.0-dev+5933
Commit b2528a6* (2015-07-12 17:39 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Julia Version 0.4.0-dev+5491
Commit cb77503 (2015-06-21 09:45 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[yuyichao]

Hmm, I could't reproduce on 0.4-dev on two different machines with LLVM-3.3 or LLVM-3.6.

[samuelpowell]

@yuyichao, one can reproduce in Juliabox.

[yuyichao]

@samuelpowell Yeah, that's true.

Somehow the llvm IR looks correct but the assembly looks wrong?

[JeffBezanson]

Looks very similar to #8932

[yuyichao]

So LLVM optimized too much after #10380 ?

[vtjnash]

code_native on a machine that gave the right answer:

    .section    __TEXT,__text,regular,pure_instructions
Filename: none
Source line: 1
    pushq   %rbp
    movq    %rsp, %rbp
Source line: 1
    vmovsd  24(%rdi), %xmm0
    vroundsd    $1, %xmm0, %xmm0, %xmm0
    vmovsd  %xmm0, -8(%rbp)
    vmovsd  16(%rdi), %xmm0
    vroundsd    $1, %xmm0, %xmm0, %xmm0
    vmovsd  %xmm0, -16(%rbp)
    vmovsd  (%rdi), %xmm0
    vmovsd  8(%rdi), %xmm1
    vroundsd    $1, %xmm0, %xmm0, %xmm0
    vroundsd    $1, %xmm1, %xmm0, %xmm1
    fldl    -8(%rbp)
    fldl    -16(%rbp)
    popq    %rbp
    ret

juliabox:

    .text
Filename: In[1]
Source line: 2
    pushq   %rbp
    movq    %rsp, %rbp
Source line: 2
    movsd   24(%rdi), %xmm0
    movabsq $140148947293360, %rax  # imm = 0x7F76F83814B0
    popq    %rbp
    jmpq    *%rax

[carnaval]

Isn't this just a (far) tail call ? Would be interesting to know where it goes.

[samuelpowell]

The jump location appears to be unstable. In one instance it seems to try to call sincos...

@code_native ltupfloor(ltup)

    .section    __TEXT,__text,regular,pure_instructions
Filename: none
Source line: 1
    pushq   %rbp
    movq    %rsp, %rbp
Source line: 1
    movsd   24(%rdi), %xmm0
    movabsq $__sincospi, %rax
    popq    %rbp
    jmpq    *%rax

[samuelpowell]

Works fine on an old build of 0.4-dev under what was then llvm-svn

Julia Version 0.4.0-dev+5312
Commit 47f697b (2015-06-11 07:05 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin14.3.0)
  CPU: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-svn

[vtjnash]

possibly the same as #7434 also

[JeffBezanson]

Also possible (fingers crossed!) it could be behind #12899 and #10908.