On Thu, 23 Jul 2026, Richard Biener wrote:
> On Thu, 23 Jul 2026, Tamar Christina wrote:
>
> > > -----Original Message-----
> > > From: Tamar Christina
> > > Sent: 22 July 2026 15:30
> > > To: Richard Biener <[email protected]>; [email protected]
> > > Cc: [email protected]; [email protected]
> > > Subject: RE: [PATCH][RFC] tree-optimization/126099 - SLP subgraph merging
> > > with low/highpart extracts
> > >
> > > > -----Original Message-----
> > > > From: Richard Biener <[email protected]>
> > > > Sent: 20 July 2026 13:19
> > > > To: [email protected]
> > > > Cc: Tamar Christina <[email protected]>;
> > > > [email protected]; [email protected]
> > > > Subject: [PATCH][RFC] tree-optimization/126099 - SLP subgraph merging
> > > with
> > > > low/highpart extracts
> > > >
> > > > The following implements merging of SLP subgraphs that overlap in
> > > > their low or highparts using VEC_PERM SLP nodes which already know
> > > > exactly how to extact half the number of lanes of another single node.
> > > >
> > > > The motivating testcase is in PR126053 coming from 508.namd_r
> > > >
> > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > >
> > > > The ??? comments show that restricting this to CSE SLP node halfs
> > > > (not vector halfs!) is probably a bit limiting if you consider
> > > > a three step 2-lane, 4-lane and 8-lane case where the 4-lane is
> > > > the lowpart of the 8-lane and the 2-lane the lowpart of the 4-lane.
> > > > That depends on the order of processing to CSE the 2-lane and if,
> > > > it will be CSEd to the 4-lane vector. I do not think we'd
> > > > handle 8-lane to 2-lane lowpart in vectorizable_slp_permutation
> > > > (but I did not perform actual experiments).
> > > >
> > > > You can see how I restrict matching in vect_cse_gather_part_starts,
> > > > but for full generality we'd have to fully populate the
> > > > stmt -> SLP node map. To get defined ordering amongst candidates
> > > > we can order the SLP node vectors in that map by the number of
> > > > lanes of the candidate node.
> > >
> > > I'm still digging through this change, but so far it seems pretty nice.
> > >
> > > >
> > > > I'll note that for 508.namd_r I only need the actual lowpart case,
> > > > not the highpart one.
> > > >
> > > > While I think the redundant lane issue is present for loops as well
> > > > I did not enable the CSE there at this point.
> > > >
> > > > Any comments? Any concerns about merging of SLP subgraphs with
> > > > differing number of lanes?
I tried to support arbitrary consecutive sub-parts, like
void foo (long *p, long *q, long *r)
{
long tem0 = r[0];
long tem1 = r[1];
long tem2 = r[2];
long tem3 = r[3];
tem0 = tem0 + 1;
tem1 = tem1 + 2;
tem2 = tem2 + 3;
tem3 = tem3 + 4;
p[0] = tem1;
p[1] = tem2;
q[0] = tem0;
q[1] = tem1;
q[2] = tem2;
q[3] = tem3;
}
where the p[] store splices out the middle of the 4 element q[] subgraph.
That works with SSE V2DI vectors as we can do a V2DI, V2DI -> V2DI
permute, but it fails with AVX2 where the naiive VEC_PERM node asks
for V4DI[, V4DI] -> V2DI permute where the x86 backend implements
neither of those and the special-case 'identity_p' which is
bool identity_p = (indices.series_p (0, 1, mask[0], 1)
&& constant_multiple_p (mask[0], nunits));
is false (due to the constant_multiple_p).
With AVX512 and V8DI vs. V2DI offsetted 6-lanes we get for the
6-lanes a AVX2 + SSE split, the SSE part can be extracted properly
aligned from V8DI but the AVX2 part is misaligned and thus fails
here.
Note that we do not consider the then promoted external permute
to be live lanes. That seems to be a bug(?), and we also do
not merge the subgraphs for costing purposes (correctly so
I think).
Most of the (current) code-gen constraints can only be verified
at the point we see the node we want to CSE, so the candidate
sets would need to be less conservatively filled, like consider
all even lanes to be extraction starts.
All of the alignment issues can of course be fixed by doing
a two-stage permutation sequence, first permute the source
in a way to present an aligned (and properly permuted)
extraction source, then extract.
I think leaving that as followup makes sense, so I'll adjust
to even lane starts plus implementing the extraction constraints
at CSE time.
Richard.
