I think that this should be handled by the BB vectorizer.

Nadav, any plans to handle this in the SLP vectorizer?

Yea, it should be easy to do. We have a few heuristics for starting an SLP chain. We should add a rule for starting a chain at a bunch of inserts.

Is this actually fixed? A quick ToT of either didn't look any better.

Yes, I checked it and it works as required

Reopening this. If we look at the equivalent c source then it appears that the vectorizer isn't working for non 128-bit vectors:

#include <x86intrin.h>

__m128 _vadd128(__m128 a, __m128 b) {
return _mm_setr_ps(
a[0] + b[0],
a[1] + b[1],
a[2] + b[2],
a[3] + b[3]);
}

__m256 _vadd256(__m256 a, __m256 b) {
return _mm256_setr_ps(
a[0] + b[0],
a[1] + b[1],
a[2] + b[2],
a[3] + b[3],
a[4] + b[4],
a[5] + b[5],
a[6] + b[6],
a[7] + b[7]);
}

clang -S -O3 pr6246.c -march=btver2 -o - -emit-llvm

; Function Attrs: norecurse nounwind readnone ssp uwtable
define <4 x float> @​_vadd128(<4 x float> %a, <4 x float> %b) local_unnamed_addr #​0 {
entry:
%0 = fadd <4 x float> %a, %b
ret <4 x float> %0
}

; Function Attrs: norecurse nounwind readnone ssp uwtable
define <8 x float> @​_vadd256(<8 x float> %a, <8 x float> %b) local_unnamed_addr #​0 {
entry:
%vecext = extractelement <8 x float> %a, i32 0
%vecext1 = extractelement <8 x float> %b, i32 0
%add = fadd float %vecext, %vecext1
%vecext2 = extractelement <8 x float> %a, i32 1
%vecext3 = extractelement <8 x float> %b, i32 1
%add4 = fadd float %vecext2, %vecext3
%vecext5 = extractelement <8 x float> %a, i32 2
%vecext6 = extractelement <8 x float> %b, i32 2
%add7 = fadd float %vecext5, %vecext6
%vecext8 = extractelement <8 x float> %a, i32 3
%vecext9 = extractelement <8 x float> %b, i32 3
%add10 = fadd float %vecext8, %vecext9
%vecext11 = extractelement <8 x float> %a, i32 4
%vecext12 = extractelement <8 x float> %b, i32 4
%add13 = fadd float %vecext11, %vecext12
%vecext14 = extractelement <8 x float> %a, i32 5
%vecext15 = extractelement <8 x float> %b, i32 5
%add16 = fadd float %vecext14, %vecext15
%vecext17 = extractelement <8 x float> %a, i32 6
%vecext18 = extractelement <8 x float> %b, i32 6
%add19 = fadd float %vecext17, %vecext18
%vecext20 = extractelement <8 x float> %a, i32 7
%vecext21 = extractelement <8 x float> %b, i32 7
%add22 = fadd float %vecext20, %vecext21
%vecinit.i = insertelement <8 x float> undef, float %add, i32 0
%vecinit1.i = insertelement <8 x float> %vecinit.i, float %add4, i32 1
%vecinit2.i = insertelement <8 x float> %vecinit1.i, float %add7, i32 2
%vecinit3.i = insertelement <8 x float> %vecinit2.i, float %add10, i32 3
%vecinit4.i = insertelement <8 x float> %vecinit3.i, float %add13, i32 4
%vecinit5.i = insertelement <8 x float> %vecinit4.i, float %add16, i32 5
%vecinit6.i = insertelement <8 x float> %vecinit5.i, float %add19, i32 6
%vecinit7.i = insertelement <8 x float> %vecinit6.i, float %add22, i32 7
ret <8 x float> %vecinit7.i
}

Must be fixed in r288412

r288412 was reverted in r288431, reopening.

I've added tests for this (128/256/512 bit float/double vectors) to llvm\test\Transforms\SLPVectorizer\X86\arith-fp.ll at r288492

Now, I think, it is finally fixed in r288497

Reverted again in r288508, reopening.

Fixed at rL289043 - it seems to have stuck this time.