This occurs due to a pattern that uses sse_load_f32/f64 with vector sqrt/rcp/rsqrt operations and turns them into scalar instructions. Perhaps for the case were the upper bits come from undef this is ok. I believe a (vzmovl load64) would do the same thing but those seems to become vzload instead and selectScalarSSELoad doesn't handle that today. In that case we should be performing the vector operation on the zeros in the upper bits which is not equivalent to using a scalar instruction.
I will remove this pattern in a follow up patch. There appears to be no other test content for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288783
91177308-0d34-0410-b5e6-
96231b3b80d8
%x2 = call <4 x float> @llvm.x86.sse.sqrt.ss(<4 x float> %x1) nounwind
ret <4 x float> %x2
}
+
+define <2 x double> @vector_sqrt_scalar_load(double* %a0) optsize {
+; CHECK-LABEL: vector_sqrt_scalar_load:
+; CHECK: ## BB#0:
+; CHECK-NEXT: vsqrtsd (%rdi), %xmm0, %xmm0
+; CHECK-NEXT: retq
+ %a1 = load double, double* %a0
+ %a2 = insertelement <2 x double> undef, double %a1, i32 0
+ %res = call <2 x double> @llvm.sqrt.v2f64(<2 x double> %a2) ; <<2 x double>> [#uses=1]
+ ret <2 x double> %res
+}
+declare <2 x double> @llvm.sqrt.v2f64(<2 x double>) nounwind readnone