[Bug tree-optimization/98542] Redundant loads in vectorised loop

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98542

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> What do you mean with "twice"?  We seem to do interleaving here (on x86_64)
> but since 'v' and 'i' have different types they do not belong to the same
> interleaving chain (but we have two that "interleave" - heh).
> 
> x.c:6:21: note:   === vect_analyze_data_ref_accesses ===
> x.c:6:21: note:   Detected single element interleaving _3->v step 16
> x.c:6:21: note:   Detected single element interleaving _3->i step 16
> 
> so if that's the main complaint then a testcase w/o gather is probably
> more relevant at first?  For x86 the two loads are offsetted by one
> element, for your asm that looks like to be the same (x5 vs x0).
Yeah, that's the main complaint.  Because we implement the interleaving
with load-lanes, the load of the “v” vector provides the corresponding
“i” vector as a byproduct.  But rather than use that “i” vector,
we load the “i” fields a second time, which again provides a vector
of the following “v” fields.  In other words, we effectively do
four loads and four permutes in order to get two vectors.

This is in contrast to targets that use separate loads and permutes,
where we only emit permutes for the vectors that we use, and where
we stand a chance of CSEing four loads into three.

It also means that we force peeling for gaps when it shouldn't be
necessary.

With the follow-on mentioned (“i” being 32-bits rather than 64) we'd
still want to treat the structure access as a single group, even though
the fields are different sizes.

Using gather seems fine to me, but then I'm biased :-)