search for: vecinit3

...readnone { entry: %0 = bitcast i32 %in.coerce to <4 x i8> %1 = extractelement <4 x i8> %0, i32 0 %conv = uitofp i8 %1 to float %vecinit = insertelement <4 x float> undef, float %conv, i32 0 %2 = extractelement <4 x i8> %0, i32 1 %conv2 = uitofp i8 %2 to float %vecinit3 = insertelement <4 x float> %vecinit, float %conv2, i32 1 %3 = extractelement <4 x i8> %0, i32 2 %conv4 = uitofp i8 %3 to float %vecinit5 = insertelement <4 x float> %vecinit3, float %conv4, i32 2 %4 = extractelement <4 x i8> %0, i32 3 %conv6 = uitofp i8 %4 to floa...

...; @test(<2 x i64> %a) { entry: %vecext = extractelement <2 x i64> %a, i32 0 %vecext1 = extractelement <2 x i64> %a, i32 1 %conv = sitofp i64 %vecext to double %conv2 = sitofp i64 %vecext1 to double %vecinit = insertelement <2 x double> undef, double %conv, i32 0 %vecinit3 = insertelement <2 x double> %vecinit, double %conv2, i32 1 ret <2 x double> %vecinit3 } With this type conversion, InstCombine will actually simplify this as expected. And I think that is the right thing to do - I can't see the scalarized version being cheaper on any target. Sinc...

...t = extractelement <2 x i64> %a, i32 0 >> %vecext1 = extractelement <2 x i64> %a, i32 1 >> %conv = sitofp i64 %vecext to double >> %conv2 = sitofp i64 %vecext1 to double >> %vecinit = insertelement <2 x double> undef, double %conv, i32 0 >> %vecinit3 = insertelement <2 x double> %vecinit, double %conv2, i32 1 >> ret <2 x double> %vecinit3 >> } >> With this type conversion, InstCombine will actually simplify this as >> expected. And I think that is the right thing to do - I can't see the >> scalari...

I have added a few PPC-specific DAG combines in the past that follow this pattern on specific operations. Now that it appears that this would be useful to do on yet another operation, I'm wondering what people think about doing this in the target-independent DAG Combiner for any legal/custom operation on the target. TL; DR; The generic pattern would look like this: (build_vector (op