search for: vecext4

...ppet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i...

...de snippet: > > for.body: ; preds = %entry, > %for.cond > %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] > %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> > %1 = extractelement <2 x i1> %0, i32 %i.022 > %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 > %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 > %cmp6 = icmp ne i32 %vecext4, %vecext5 > %cmp7 = xor i1 %1, %cmp6 > > ... > > and the SelectionDAG before TypeLegalizer is like this. &g...

...as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken...

...as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken...

...imal code. If we also handle shuffles of input vectors, we can catch things such as the following: define dso_local <4 x float> @test(<4 x i32> %a, <4 x i32> %b) { entry: %vecext = extractelement <4 x i32> %a, i32 0 %vecext1 = extractelement <4 x i32> %a, i32 1 %vecext4 = extractelement <4 x i32> %b, i32 2 %vecext7 = extractelement <4 x i32> %b, i32 3 %conv = sitofp i32 %vecext to float %conv2 = sitofp i32 %vecext1 to float %conv5 = sitofp i32 %vecext4 to float %conv8 = sitofp i32 %vecext7 to float %vecinit = insertelement <4 x float>...

...s, we can catch things such as >> the following: >> define dso_local <4 x float> @test(<4 x i32> %a, <4 x i32> %b) { >> entry: >> %vecext = extractelement <4 x i32> %a, i32 0 >> %vecext1 = extractelement <4 x i32> %a, i32 1 >> %vecext4 = extractelement <4 x i32> %b, i32 2 >> %vecext7 = extractelement <4 x i32> %b, i32 3 >> %conv = sitofp i32 %vecext to float >> %conv2 = sitofp i32 %vecext1 to float >> %conv5 = sitofp i32 %vecext4 to float >> %conv8 = sitofp i32 %vecext7 to float...

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