[PATCH] D94708: [IR] Introduce llvm.experimental.vector.splice intrinsic

Cullen Rhodes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 18 07:18:43 PST 2021


c-rhodes marked 2 inline comments as done.
c-rhodes added a comment.

In D94708#2512706 <https://reviews.llvm.org/D94708#2512706>, @fhahn wrote:

> In D94708#2509677 <https://reviews.llvm.org/D94708#2509677>, @c-rhodes wrote:
>
>> In D94708#2509610 <https://reviews.llvm.org/D94708#2509610>, @fhahn wrote:
>>
>>> Are there plans to use this for fixed vectors as well? If not, can this be restricted to scalable vectors only? It seems like for fixed vectors, preferring the `shufflevector` versions would be beneficial, to avoid having to update all transforms lookin at shuffles.
>>>
>>> Otherwise, this should probably have some tests for platforms other than AArch64 and also support in GlobalISel, which is the default on AArch64 with `-O0` IIRC (or do the transform to shuffles as an IR transform).
>>
>> The named shufflevector intrinsics accept both fixed and scalable vectors but for fixed they map to existing shufflevector.
>
> As specified here yes, but I was wondering if they actually need to support fixed-width vectors? Is there a reason to use the intrinsics with fixed vectors instead of shuffles?

I noticed there was a similar discussion on D94883 <https://reviews.llvm.org/D94883>, as mentioned I've took the same approach and made it explicit in the LangRef that shufflevector should be used instead for this intrinsic whilst it's experimental.



================
Comment at: llvm/docs/LangRef.rst:16244-16245
+``trailing.elts`` is an integer constant that specifies the number of trailing
+elements to extract from the first vector, if this exceeds the known minimum
+number of elements in the first vector, it is clamped. ``trailing.elts`` is
+treated as an unsigned value.
----------------
paulwalker-arm wrote:
> This restriction does not make sense to me.  The logical requirement is for the trailing elements to be less than or equal to the full runtime-time vector length.  Then I'd say that counts beyond this range result in poison.  
> This restriction does not make sense to me.  The logical requirement is for the trailing elements to be less than or equal to the full runtime-time vector length.  Then I'd say that counts beyond this range result in poison.  

My mistake, you're right it should be the full runtime time VL rather than minimum number of elements. LangRef has been updated.


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

https://reviews.llvm.org/D94708



More information about the llvm-commits mailing list