search for: vecext

...ikely) that on some targets, doing the insert with integers and then converting the vector is cheaper (although this is definitely not the case with PPC). But what I am proposing here is actually handling something like this: define dso_local <2 x double> @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> %v...

...egers and then >> converting the vector is cheaper (although this is definitely not the case >> with PPC). >> But what I am proposing here is actually handling something like this: >> define dso_local <2 x double> @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 >> %v...

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