[LLVMbugs] [Bug 21365] Mesa llvmpipe lp_test_format regression with llvm-3.6.0svn

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21365

Jose Fonseca <jfonseca at vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Jose Fonseca <jfonseca at vmware.com> ---
This might not be a regressions in LLVM per se, but rather a LLVM change
exposing a pre-existing bug in this test.

$ gdb --args ./lp_test_format -v -v
[...]

define void @fetch_r32g32b32a32_float_float(<4 x float>*, i8*, i32, i32) {
entry:
  %4 = getelementptr i8* %1, i32 0
  %5 = bitcast i8* %4 to i128*
  %6 = load i128* %5
  %7 = bitcast i128 %6 to <4 x float>
  store <4 x float> %7, <4 x float>* %0
  ret void
}


     0:        pushq    %rbp
     1:        movq    %rsp, %rbp
     4:        vmovaps    (%rsi), %xmm0
     8:        vmovaps    %xmm0, (%rdi)
    12:        popq    %rbp
    13:        retq

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ff7004 in ?? ()
(gdb) bt
#0  0x00007ffff7ff7004 in ?? ()
#1  0x00007fffffffe210 in ?? ()
#2  0x0000000000407174 in test_format_float (verbose=0, fp=0x7fffffffe160,
desc=0x217fdf0) at src/gallium/drivers/llvmpipe/lp_test_format.c:168
Backtrace stopped: frame did not save the PC
(gdb) disassemble 0x00007ffff7ff7000,0x00007ffff7ff7010
Dump of assembler code from 0x7ffff7ff7000 to 0x7ffff7ff7010:
   0x00007ffff7ff7000:    push   %rbp
   0x00007ffff7ff7001:    mov    %rsp,%rbp
=> 0x00007ffff7ff7004:    vmovaps (%rsi),%xmm0
   0x00007ffff7ff7008:    vmovaps %xmm0,(%rdi)
   0x00007ffff7ff700c:    pop    %rbp
   0x00007ffff7ff700d:    retq   
   0x00007ffff7ff700e:    add    %al,(%rax)
End of assembler dump.
(gdb) p /x $rsi
$2 = 0x1271e2c


The code generated by LLVM looks fine.  The problem is that caller is not
passing an aligned vector.


It seems that before, LLVM would generate the following assembly for the same
IR:

     0:        pushq    %rbp
     1:        movq    %rsp, %rbp
     4:        movq    (%rsi), %rax
     7:        movq    8(%rsi), %rcx
    11:        movq    %rcx, 8(%rdi)
    15:        movq    %rax, (%rdi)
    18:        popq    %rbp
    19:        retq

hence avoiding the problem.


In other words, Vinson, I think we should close this issue and file another on
FDO bug tracker.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141024/5ae1e0aa/attachment.html>