[PATCH] D71636: [AArch64][SVE][WIP] Add support for vscale constants (?)

Chris Lattner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 9 15:28:36 PST 2020


lattner added a comment.

In D71636#1813285 <https://reviews.llvm.org/D71636#1813285>, @efriedma wrote:

> In D71636#1807522 <https://reviews.llvm.org/D71636#1807522>, @simoll wrote:
>
> > If shuffle masks are no longer IR entities, this means ruling  out computed shuffle masks in the future, which are available on some targets (X86). Whether we want computed shuffle masks at all is a different question.
>
>
> Yes, this is kind of a decision point: either we allow computed shufflemasks, or we get rid of the operand altogether.  Or we can introduce some intrinsics and put off the decision, I guess.
>
> I don't think there's much incentive to support computed shuffle masks.  Yes, x86 has pshufb, but that doesn't generalize to other element widths/two source vectors/etc. easily.  And there aren't very many practical use cases for computed shuffles in automatic vectorization.
>
> If we allow computed shuffle masks, there's also the minor complication that we'd have to change shufflevector to produce poison, not undef, for undef indexes.  But we can likely change that with some work...


Altivec also supports computed shuffles with vperm IIRC.  The problem with this in a shufflevector context is that each of these are very different in how they model a computed shuffle.  I would personally rather (keep!) shufflevector to static shuffle masks as a target independent concept.  If there becomes a good abstraction for computed shuffles, we can introduce a new intrinsic or instruction at that time, which is separate from it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71636/new/

https://reviews.llvm.org/D71636





More information about the llvm-commits mailing list