[llvm] [InterleavedAccess] Construct interleaved access store with shuffles (PR #167737)

[Paul Walker via llvm-commits]

paulwalker-arm wrote:

My takeaway from this PR is that it is vastly complicated for what it is trying to achieve. I'll caveat my comment by saying I don't much like this pass.  From what I can see you are tackling two independent problems:

1. Improving the code generation of large shuffles that can be decomposed into sequences of zip/uzp patterns.
2. Aggressively introducing struct stores to remove some of the sequences that result from (1).

Perhaps the work can be split on those boundaries because looking at the original test output I suspect (1) could be a significant win without necessarily needing (2).

Just thinking on (2) I wonder if instead of the code rewriting the shuffle it could instead shuffle the original shuffled data? (i.e. to account for the implicit shuffle performed by the structure store).  That seems like a simpler implementation but I don't know if it will result in the same generated code. That said, if it does not then to me that is a sign of us not doing a good enough job of optimising shuffle sequences, which kind of brings us back to (1).

As a final thought, we do have the (de)interleave intrinsics, which might be easier to work with? [1] I have raised https://github.com/llvm/llvm-project/pull/169700 so the bigger power-of-two variants work for NEON. I mention this because in some ways the hardwork has been done by the InterleavePass in identifying the (de)interleaving factor and so it might be easier to replace the shuffle with a call to the equivalent intrinsic.  Then you can leave the code generator to emit optimised zip/uzp patterns.

[1] I don't know which factors you're most interested in but previously it was suggested that we should introduce intrinsics where the factor is passed in (rather than having an intrinsic per factor). I think such an approach would make my suggestions above easier still.

https://github.com/llvm/llvm-project/pull/167737