[llvm] [LoongArch] Custom lower vecreduce_add. (PR #154304)

[via llvm-commits]

================
@@ -1,27 +1,18 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
-
 ; RUN: llc --mtriple=loongarch64 --mattr=+lasx %s -o - | FileCheck %s
 
 define void @vec_reduce_add_v32i8(ptr %src, ptr %dst) nounwind {
 ; CHECK-LABEL: vec_reduce_add_v32i8:
 ; CHECK:       # %bb.0:
 ; CHECK-NEXT:    xvld $xr0, $a0, 0
-; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 78
-; CHECK-NEXT:    xvshuf4i.b $xr1, $xr1, 228
-; CHECK-NEXT:    xvadd.b $xr0, $xr0, $xr1
-; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 68
-; CHECK-NEXT:    xvbsrl.v $xr1, $xr1, 8
-; CHECK-NEXT:    xvadd.b $xr0, $xr0, $xr1
-; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 68
-; CHECK-NEXT:    xvsrli.d $xr1, $xr1, 32
-; CHECK-NEXT:    xvadd.b $xr0, $xr0, $xr1
-; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 68
-; CHECK-NEXT:    xvshuf4i.b $xr1, $xr1, 14
-; CHECK-NEXT:    xvadd.b $xr0, $xr0, $xr1
-; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 68
-; CHECK-NEXT:    xvrepl128vei.b $xr1, $xr1, 1
-; CHECK-NEXT:    xvadd.b $xr0, $xr0, $xr1
-; CHECK-NEXT:    xvstelm.b $xr0, $a1, 0, 0
+; CHECK-NEXT:    xvhaddw.h.b $xr0, $xr0, $xr0
+; CHECK-NEXT:    xvhaddw.w.h $xr0, $xr0, $xr0
+; CHECK-NEXT:    xvhaddw.d.w $xr0, $xr0, $xr0
+; CHECK-NEXT:    xvhaddw.q.d $xr0, $xr0, $xr0
+; CHECK-NEXT:    xvpermi.d $xr1, $xr0, 2
+; CHECK-NEXT:    xvadd.d $xr0, $xr1, $xr0
+; CHECK-NEXT:    xvpickve2gr.d $a0, $xr0, 0
----------------
heiher wrote:

Yeah. In the current test, the extension bits of the result are not relevant. What I mean is that in some related cases (for example, adding new test cases), should the selection of the `xvpickve2gr.[b,bu]` instruction be handled in this patch?

```llvm
define signext i8 @vec_reduce_add_v32i8(ptr %src) nounwind {
  %v = load <32 x i8>, ptr %src
  %res = call i8 @llvm.vector.reduce.add.v32i8(<32 x i8> %v)
  ret i8 %res
}
```

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