[llvm] [AArch64] Address issue reported in PR#196029 (PR #199122)

[Paul Walker via llvm-commits]

================
@@ -202,4 +202,31 @@ define void @store_trunc_v32i16i8(ptr %ap, ptr %dest) #0 {
   ret void
 }
 
+define void @store_trunc_v4i64i32_neon_sve(ptr %src, ptr %dest) vscale_range(1,0) "target-features"="+neon,+sve" {
+; CHECK-LABEL: store_trunc_v4i64i32_neon_sve:
+; CHECK:       // %bb.0:
+; CHECK-NEXT:    ldp q1, q0, [x0]
+; CHECK-NEXT:    uzp1 v0.4s, v1.4s, v0.4s
+; CHECK-NEXT:    str q0, [x1]
+; CHECK-NEXT:    ret
+  %ld = load <4 x i64>, ptr %src, align 4
+  %trunc = trunc <4 x i64> %ld to <4 x i32>
+  store <4 x i32> %trunc, ptr %dest, align 8
+  ret void
+}
----------------
paulwalker-arm wrote:

It's a weird relationship whereby SVE is not really an extension of NEON but it's not fully independent of it either.  The closes you get to SVE being independent is Streaming-SVE, but even then there are a handful of NEON instructions that remain available.  At the C++ level this is why you'll see `Subtarget->isNeonAvailable()` used more often than `Subtarget->hasNEON()` to disambiguate the available NEON instructions from the feature itself. 

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