[LLVMbugs] [Bug 17185] New: match broadcast instruction to data type (int or FP)
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue Sep 10 10:17:59 PDT 2013
http://llvm.org/bugs/show_bug.cgi?id=17185
Bug ID: 17185
Summary: match broadcast instruction to data type (int or FP)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedbugs at nondot.org
Reporter: kkhoo at perfwizard.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Here's a function with codegen for an AVX2-equipped machine. I think LLVM does
a decent job generating the main loop to store using AVX instructions 16-bytes
at a time (could have used 32-byte stores?), but there appears to be an
instruction selection problem because 'vbroadcastsd' is used to splat the
integer values into a ymm register.
Intel added integer variants of the broadcast instructions with AVX2 because
there's a hardware penalty for mixing integer and FP data in the CPU (
explanation from Intel here:
http://software.intel.com/en-us/forums/topic/280799 ). It would be better if
LLVM used 'vpbroadcastd' in this code.
$ ./clang -v
clang version 3.4 (trunk 189776)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
$ cat broadcast.c
void foo(int *x, int n, int val) {
int i;
for(i=0; i<n; i++) {
x[i] = val + i;
}
}
$ ./clang -S -O3 -fomit-frame-pointer -march=core-avx2 -o /dev/stdout
broadcast.c
.section __TEXT,__text,regular,pure_instructions
.section __TEXT,__const
.align 5
LCPI0_0:
.quad 4 ## 0x4
.quad 5 ## 0x5
.quad 6 ## 0x6
.quad 7 ## 0x7
LCPI0_1:
.quad 0 ## 0x0
.quad 1 ## 0x1
.quad 2 ## 0x2
.quad 3 ## 0x3
LCPI0_2:
.long 0 ## 0x0
.long 2 ## 0x2
.long 4 ## 0x4
.long 6 ## 0x6
.long 0 ## 0x0
.long 0 ## 0x0
.long 0 ## 0x0
.long 0 ## 0x0
LCPI0_3:
.quad 8 ## 0x8
.quad 9 ## 0x9
.quad 10 ## 0xa
.quad 11 ## 0xb
.section __TEXT,__text,regular,pure_instructions
.globl _foo
.align 4, 0x90
_foo: ## @foo
.cfi_startproc
## BB#0: ## %entry
testl %esi, %esi
jle LBB0_7
## BB#1: ## %for.body.lr.ph
movl $2863311531, %eax ## imm = 0xAAAAAAAB
movl %esi, %r8d
imulq %r8, %rax
shrq $35, %rax
imull $12, %eax, %ecx
xorl %r9d, %r9d
movl %esi, %eax
subl %ecx, %eax
testl %ecx, %ecx
je LBB0_4
## BB#2: ## %vector.ph
movslq %edx, %r10
movq %r8, %r9
subq %rax, %r9
movl %eax, %ecx
movq %r8, %r11
subq %rcx, %r11
xorl %ecx, %ecx
vmovd %r10, %xmm0
vbroadcastsd %xmm0, %ymm0
vmovdqa LCPI0_0(%rip), %ymm1
vmovdqa LCPI0_1(%rip), %ymm2
vmovdqa LCPI0_2(%rip), %ymm3
vmovdqa LCPI0_3(%rip), %ymm4
.align 4, 0x90
LBB0_3: ## %vector.body
## =>This Inner Loop Header: Depth=1
vmovd %rcx, %xmm5
vpermq $0, %ymm5, %ymm5 ## ymm5 = ymm5[0,0,0,0]
vpaddq %ymm1, %ymm5, %ymm6
vpaddq %ymm2, %ymm5, %ymm7
vpaddq %ymm0, %ymm7, %ymm7
vpermd %ymm7, %ymm3, %ymm7
vmovdqu %xmm7, (%rdi,%rcx,4)
vpaddq %ymm0, %ymm6, %ymm6
vpaddq %ymm4, %ymm5, %ymm5
vpaddq %ymm0, %ymm5, %ymm5
vpermd %ymm5, %ymm3, %ymm5
vpermd %ymm6, %ymm3, %ymm6
leaq 12(%rcx), %rax
cmpq %rax, %r11
vmovdqu %xmm6, 16(%rdi,%rcx,4)
vmovdqu %xmm5, 32(%rdi,%rcx,4)
movq %rax, %rcx
jne LBB0_3
LBB0_4: ## %middle.block
cmpq %r9, %r8
je LBB0_7
## BB#5: ## %for.body.preheader
leaq (%rdi,%r9,4), %rax
subl %r9d, %esi
addl %r9d, %edx
.align 4, 0x90
LBB0_6: ## %for.body
## =>This Inner Loop Header: Depth=1
movl %edx, (%rax)
incl %edx
addq $4, %rax
decl %esi
jne LBB0_6
LBB0_7: ## %for.end
vzeroupper
ret
--
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/20130910/84fdb079/attachment.html>
More information about the llvm-bugs
mailing list