https://llvm.org/bugs/show_bug.cgi?id=29010
Bug ID: 29010
Summary: Bad instruction encoding in 32-bit code on haswell
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: andrew.b.ad...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16970
--> https://llvm.org/bugs/attachment.cgi?id=16970&action=edit
.ll that reproduces the issue
Some time in between r278315 and r278321 jitting 32-bit code for processors
with avx broke for me for some test cases (the generated code segfaults where
it didn't before).
The attached .ll file reproduces the problem with the following llc invocation:
$ llc test.ll -filetype=obj -O3 -mcpu=haswell -o test.o
$ otool -tv test.o | grep ld
000005f5 ldsl 0x7f8dd52a(%edx), %edi
The code faults at the ldsl instruction. Reading up on it, I don't think that's
an instruction that this .ll should be generating. Indeed if I get llvm to emit
asm directly I see no such instruction:
$ llc test.ll -filetype=asm -O3 -mcpu=haswell -o - | grep ldsl
Lining things up using the surrounding code, here's the block of asm from llc
-> asm directly:
movl 4(%edi), %ebp
addl (%edi), %ebp
vcvtsi2ssl %ebp, %xmm8, %xmm2
leal 4(%edi), %edi
vmovss %xmm2, (%edx)
addl $4, %edx
and here it is from llc -> object file -> otool:
000005f0 movl 0x4(%edi), %ebp
000005f3 addl (%edi), %ebp
000005f5 ldsl 0x7f8dd52a(%edx), %edi
000005fb addb $-0x3b, %al
000005fd cli
000005fe adcl %edx, (%edx)
00000600 addl $0x4, %edx
So vcvtsi2ssl is messed up. Perhaps there's a problem with the instruction
encoding changes in that commit range?
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
