http://llvm.org/bugs/show_bug.cgi?id=21771
Bug ID: 21771
Summary: consecutive stores not merged optimally
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
Marking this as an x86 bug, but it probably applies to any target that has
reasonably fast unaligned memops (and therefore could be fixed at a higher
level):
$ cat bad_store_merge.ll
define <4 x double> @bad_store_merge(double* %ptr) {
%a = load double* %ptr, align 8
%vecinit = insertelement <4 x double> undef, double %a, i32 0
%arrayidx1 = getelementptr inbounds double* %ptr, i64 1
%b = load double* %arrayidx1, align 8
%vecinit2 = insertelement <4 x double> %vecinit, double %b, i32 1
%arrayidx3 = getelementptr inbounds double* %ptr, i64 2
%c = load double* %arrayidx3, align 8
%vecinit4 = insertelement <4 x double> %vecinit2, double %c, i32 2
%arrayidx5 = getelementptr inbounds double* %ptr, i64 3
%d = load double* %arrayidx5, align 8
%vecinit6 = insertelement <4 x double> %vecinit4, double %d, i32 3
ret <4 x double> %vecinit6
}
bin$ ./llc -mcpu=core2 bad_store_merge.ll -o -
...
movsd 16(%rdi), %xmm1
movhpd 24(%rdi), %xmm1
movups (%rdi), %xmm0
retq
We should have combined the 'movsd' and 'movhpd' into one store, so the ideal
codegen for this target (not AVX, so no 256-bit memops) would be:
movups (%rdi), %xmm0
movups 16(%rdi), %xmm1
retq
This is a follow-on from bug 21710. I think it's a problem in
SelectionDAG::isConsecutiveLoad().
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
