[clang] [CIR][AArch64] Upstream narrowing-addition NEON builtins (PR #204989)

[Vicky Nguyen via cfe-commits]

================
@@ -1073,6 +1098,20 @@ static mlir::Value emitCommonNeonBuiltinExpr(
     mlir::Type resultType = cgf.convertType(expr->getType());
     return cgf.getBuilder().createBitcast(result, resultType);
   }
+  case NEON::BI__builtin_neon_vraddhn_v: {
+    cir::VectorType srcTy =
+        cgf.getBuilder().getExtendedOrTruncatedElementVectorType(
+            vTy, /*isExtended=*/true);
+
+    llvm::StringRef llvmIntrName = getLLVMIntrNameNoPrefix(
+        static_cast<llvm::Intrinsic::ID>(llvmIntrinsic));
+    mlir::Value result =
+        emitNeonCall(cgf.getCIRGenModule(), cgf.getBuilder(),
+                     /*argTypes=*/{srcTy, srcTy}, ops, llvmIntrName,
+                     /*funcResTy=*/vTy, loc);
+    mlir::Type resultType = cgf.convertType(expr->getType());
+    return cgf.getBuilder().createBitcast(result, resultType);
+  }
----------------
iamvickynguyen wrote:

> But since we truncate after that, does it matter whether we use lshr or ashr?

It's true that after truncating, it doesn't matter. However, the tests have `lshr` checks. For example
https://github.com/llvm/llvm-project/pull/204989/changes#diff-2b97ecf3f67118099b37543f4ca652bebfa9bf2ed58e590d4cf68671b1e5ab6aR1005

> It's fine to leave this as is, but could you add a comment with rationale for the bitcast? And would you be able to remove the dead code in ARM.cpp? Perhaps in a separate PR? Thank you 🙏🏻

I've added comments to both `CIRGenBuiltinAArch64.cpp` and `ARM.cpp`. Interestingly, I discovered that the bitcasts in ARM.cpp aren't dead code :smile: Without them, LShr crashes because of the operand types mismatch. Another thing is without bitcasts, the Add works on <16 x i8> instead of <8 x i16> which might produce wrong results (I'm not too sure about that :smile: ).

> This is a bit convoluted, but should work for you nicely if you just move the definition of srcTy out of this switch stmt, right?

Unfortunately, we can't move `srcTy` out of this switch statement because `getExtendedOrTruncatedElementVectorType` has an assert `"expected int vector"`. For example, `vadd_f32` has elementType float, so it triggers the assertion.

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