[PATCH] D32530: [SVE][IR] Scalable Vector IR Type

[Graham Hunter via Phabricator via llvm-commits]

huntergr added a comment.

In D32530#1468145 <https://reviews.llvm.org/D32530#1468145>, @simoll wrote:

> That's pretty much what LLVM-VP is about: https://reviews.llvm.org/D57504
>
> We are proposing compress/expand and lane shift as intrinsics.
>  I suggest you add any shuffle intrinsics to the same namespace to avoid fragmentation.


I'm hoping we can use an extended shufflevector for this still, but if we do end up going down the extra intrinsics route then I'll certainly use the same namespace.

> IMHO, the redesigned reduction intrinsics should go there as well (https://reviews.llvm.org/D60261 and/or https://reviews.llvm.org/D60262).
> 
>> 
>> 
>>> 
>>> 
>>>> 2. Introduce additional intrinsics for the other shuffle variants as needed
>>>> 3. Allow shufflevector to accept arbitrary masks so that intrinsics can be used (though possibly only if the output vector is scalable).
> 
> Even if shuffle masks don't need to be constants anymore, it will be awkward to encode compress/expand without additional intrinsics (you would need a prefix sum vector over the mask bits or similar).

Agreed, and it also extends to predicated inserts and extracts -- using SVE's 'lasta/lastb' instructions in a vectorized loop tail, for example -- they don't map well to the current instructions, so would need intrinsics.

> 
> 
>>> This warrants a larger discussion, which would hinder the current progress.
>> 
>> I agree. We should have a separate RFC on this.
> 
> +1

Agreed. Handling shuffles was part of the original RFC, but that RFC was far too large to discuss all at once. I've started reworking that section based on current feedback, and I'll send it out once ready.


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

https://reviews.llvm.org/D32530