[llvm-branch-commits] [llvm] [LoongArch] Pre-commit tests for shuffle visiting same lane. NFC (PR #151633)

[via llvm-branch-commits]

================
@@ -97,3 +157,16 @@ define <4 x double> @shuffle_v4f64(<4 x double> %a) {
   %shuffle = shufflevector <4 x double> %a, <4 x double> poison, <4 x i32> <i32 3, i32 1, i32 2, i32 0>
   ret <4 x double> %shuffle
 }
+
+define <4 x double> @shuffle_v4f64_same_lane(<4 x double> %a) {
+; CHECK-LABEL: shuffle_v4f64_same_lane:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    pcalau12i $a0, %pc_hi20(.LCPI11_0)
+; CHECK-NEXT:    xvld $xr1, $a0, %pc_lo12(.LCPI11_0)
+; CHECK-NEXT:    xvpermi.d $xr0, $xr0, 78
+; CHECK-NEXT:    xvshuf.d $xr1, $xr0, $xr0
+; CHECK-NEXT:    xvori.b $xr0, $xr1, 0
----------------
zhaoqi5 wrote:

Yes, a single `xvpermi.d` is enough for this case.

But now, when we legalize `vector_shuffle` for lasx, we firstly use `canonicalizeShuffleVectorByLane()` to convert the source vector to avoid cross-lane access. Thus the `xvpermi.d $xr0, $xr0, 78` will be generated. Then the converted vector will be used to match lasx shuffle instructions' patterns, and `xvshuf` maches.

To avoid this, we may should modify the order of the current processing logic. And the pattern for `xvpermi.d` should also be implemented.

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