[llvm] [IR] Split vector.splice into vector.splice.down and vector.splice.up (PR #170796)

[Luke Lau via llvm-commits]

================
@@ -20729,30 +20729,79 @@ Arguments:
 All arguments must be vectors of the same type whereby their logical
 concatenation matches the result type.
 
-'``llvm.vector.splice``' Intrinsic
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+'``llvm.vector.splice.down``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic.
+
+::
+
+      declare <2 x double> @llvm.vector.splice.down.v2f64(<2 x double> %vec1, <2 x double> %vec2, i32 %imm)
+      declare <vscale x 4 x i32> @llvm.vector.splice.down.nxv4i32(<vscale x 4 x i32> %vec1, <vscale x 4 x i32> %vec2, i32 %imm)
+
+Overview:
+"""""""""
+
+The '``llvm.vector.splice.down.*``' intrinsics construct a vector by
+concatenating two vectors together, shifting the elements down by ``imm``, and
+extracting the lower half.
+
+This is equivalent to :ref:`llvm.fshr.* <int_fshr>`, but operating on elements
+instead of bits.
+
+These intrinsics work for both fixed and scalable vectors. While this intrinsic
+supports all vector types the recommended way to express this operation for
+fixed-width vectors is still to use a shufflevector, as that may allow for more
+optimization opportunities.
+
+For example:
+
+.. code-block:: text
+
+ llvm.vector.splice.down(<A,B,C,D>, <E,F,G,H>, 1);
+		     ==> <A,B,C,D,E,F,G,H>
+		     ==> <B,C,D,E,F,G,H,_>
+		     ==> <B,C,D,E>
+
+
+Arguments:
+""""""""""
+
+The first two operands are vectors with the same type. The start index is imm
+modulo the runtime number of elements in the source vector. For a fixed-width
+vector <N x eltty>, imm is an unsigned integer constant in the range
+0 <= imm <= N. For a scalable vector <vscale x N x eltty>, imm is an unsigned
+integer constant in the range 0 <= imm <= X where X=vscale_range_min * N.
----------------
lukel97 wrote:

I think we need to distinguish them because we don't allow the full range for scalable vectors, i.e. we cap it at vscale_range_min. But agreed, we can remove this distinction if/when we relax this to "immediates that exceed the runtime length of the vector are poison". 

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