[llvm] [LoongArch] Optimize 128-to-256-bit vector insertion and 256-to-128-bit subvector extraction (PR #146300)

[via llvm-commits]

================
@@ -1879,6 +1873,35 @@ def : Pat<(loongarch_xvmskgez (v32i8 LASX256:$vj)), (PseudoXVMSKGEZ_B LASX256:$v
 def : Pat<(loongarch_xvmskeqz (v32i8 LASX256:$vj)), (PseudoXVMSKEQZ_B LASX256:$vj)>;
 def : Pat<(loongarch_xvmsknez (v32i8 LASX256:$vj)), (PseudoXVMSKNEZ_B LASX256:$vj)>;
 
+// Subvector tricks
+// Patterns for insert_subvector/extract_subvector
+multiclass subvector_subreg_lowering<RegisterClass subRC, ValueType subVT,
+                                     RegisterClass RC, ValueType VT,
+                                     int hiIdx, SubRegIndex subIdx> {
+  // A 128-bit subvector extract from the first 256-bit vector position is a
+  // subregister copy that needs no instruction. Likewise, a 128-bit subvector
+  // insert to the first 256-bit vector position is a subregister copy that needs
+  // no instruction.
+  def : Pat<(subVT (extract_subvector (VT RC:$src), (iPTR 0))),
+            (subVT (EXTRACT_SUBREG RC:$src, subIdx))>;
+  def : Pat<(VT (insert_subvector undef_or_freeze_undef, subRC:$src, (iPTR 0))),
+            (VT (INSERT_SUBREG (IMPLICIT_DEF), subRC:$src, subIdx))>;
+
+  def : Pat<(subVT (extract_subvector (VT RC:$src), (iPTR hiIdx))),
----------------
tangaac wrote:

`xvpermi.q $xd, $xj 1`  would change the `$xj` register  if `xj == xd`

And many cases show this change.
e.g. https://github.com/tangaac/loong-opt-cov-ts/commit/c0576ea2cba7b75486cdfd070ebab1d762044296#diff-364b3817b5e53b0b599b12041f8b1377a5d7c6f473fa5d3c75db971e939debb5L2105-R2165

We could use `xvpermi.d $xd, $xj, 14` to avoid this.

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