[Bug target/82136] x86: -mavx256-split-unaligned-load should try to fold other shuffles into the load/vinsertf128

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes <peter at cordes dot ca> ---
(In reply to Richard Biener from comment #2)
> And it gets worse because of the splitting
> which isn't exposed to the vectorizer.

Split loads/stores can be a useful shuffling strategy even on Haswell/Skylake
(which don't normally benefit from split loads/stores for contiguous but
unaligned).   vinsertf128 from memory only requires a load uop + blend uop
which can run on any of the three vector ALU ports.  (The register-source
version is a shuffle, though.)  vextractf128 is a pure store with no ALU, but
the store-address and store-data uops can't micro-fuse.  If store-port
throughput isn't a problem but shuffle throughput is, it could be a win.

Unaligned overlapping loads are another interesting way to replace shuffles in
some cases.

> not sure what ends up messing things up here (I guess AVX256 doesn't have
> full width extract even/odd and interleave high/low ...).

 Yep, replied to that in detail at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82137#c2

> Looks like with -mprefer-avx128 we never try the larger vector size (Oops?).
> At least we figure vectorization isn't profitable.

 AVX actually makes the SSE2 vectorization strategy a lot better (saves a lot
of movdqa reg,reg copies), and it implies that the CPU has efficient unaligned
vector load/store.  So probably the best choice for -mavx -mprefer-avx128 is to
vectorize like SSE2, but with unaligned loads/stores.

256b lane-crossing shuffles are extra expensive with -mtune=znver1 and
-mtune=bdver* (which enable -mprefer-avx128), so it's a good thing that
-mprefer-avx128 doesn't enable the current AVX1/2 256b vectorization strategy. 
(Which is horrible in this case anyway: bug 82137).

With a good 256b vectorization strategy, it might be a win for Ryzen (which,
unlike Bulldozer-family, has better total uop throughput when running 2-uop
instructions like AVX 256b according to Agner Fog, so -mprefer-avx128 isn't
always appropriate for Ryzen.)

> So all this probably boils down to costs of permutes not being modeled.

That would certainly explain gcc's behaviour in a lot of cases.  It often seems
pretty shuffle-happy, even though shuffles are a very limited execution
resource.  (Especially with unrolling so front-end bottlenecks don't hide the
shuffle bottlenecks.)