[llvm-dev] LoopVectorizer: shufflevectors

[Renato Golin via llvm-dev]

On Wed, 5 Sep 2018 at 02:58, Saito, Hideki <hideki.saito at intel.com> wrote:
> I think we should talk about how much complexity we would be adding for general "vectorized load/store optimization", and whether we should have a separate post-vectorizer optimizer doing it (while LV still needs to understand the cost modeling aspect of that optimization, in order to choose the right VF).

I imagine it would be a lot easier to plug loop-vectorisation-specific
clean up passes in a VPlan model than today. But as you said, this is
only part of the vectorised code the middle end generates.

While LV could (potentially) generate less bloated code, which would
also help clean up passes to do their jobs better, it will have to be
very conservative and extensively tested.


> This should include a discussion about moving interleave memory access optimization from LV to there. Adding a small new optimization here and there to LV can have a snowball effect.

I agree that interleave access is not exclusive to loop vectorisation
and that it should be moved to a higher position (some of your patches
earlier this year come to mind).

But, as I said back then, before we do so, we need to understand
exactly where to put it. That will depend on what other passes will
actually use it and if we want it to be a utility class or an analysis
pass, or both.

Have you compiled a list of passes that could benefit from such a move?

cheers,
--renato