[LLVMbugs] [Bug 22685] New: making zeros the hard way: scalar load into zero vector (AVX)
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue Feb 24 14:06:46 PST 2015
http://llvm.org/bugs/show_bug.cgi?id=22685
Bug ID: 22685
Summary: making zeros the hard way: scalar load into zero
vector (AVX)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedbugs at nondot.org
Reporter: spatel+llvm at rotateright.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
$ cat insert.ll
define <8 x float> @mov00(float* %ptr) {
%val = load float* %ptr
%vec = insertelement <8 x float> zeroinitializer, float %val, i32 0
ret <8 x float> %vec
}
Using llc built from r230234:
$ ./llc insert.ll -o - -mattr=avx
...
vxorps %xmm0, %xmm0, %xmm0
vinsertps $0, (%rdi), %xmm0, %xmm0 ## xmm0 = mem[0],xmm0[1,2,3]
vxorps %ymm1, %ymm1, %ymm1
vinsertf128 $0, %xmm0, %ymm1, %ymm0
retq
But if we change the vector to be undef initialized:
%vec = insertelement <8 x float> undef, float %val, i32 0
We get the expected:
vmovss (%rdi), %xmm0 ## xmm0 = mem[0],zero,zero,zero
retq
-----------------------------------------------------------------------------
This may be complicated by the fact that a non-VEX prefix 'movss' leaves the
upper 128-bit undef.
But with AVX, the Intel manual says:
VMOVSS (VEX.NDS.128.F3.0F 10 /r when the source operand is memory and the
destination is an XMM register)
DEST[31:0] <- SRC[31:0]
DEST[VLMAX-1:32] <- 0
--
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/20150224/28815614/attachment.html>
More information about the llvm-bugs
mailing list