================
@@ -369,12 +369,96 @@ static mlir::Value emitCommonNeonSISDBuiltinExpr(
   case NEON::BI__builtin_neon_vmaxv_f32:
   case NEON::BI__builtin_neon_vmaxvq_f32:
   case NEON::BI__builtin_neon_vmaxvq_f64:
-    return emitNeonCall(cgf.cgm, cgf.getBuilder(),
-                        {cgf.convertType(expr->getArg(0)->getType())}, ops,
-                        llvmIntrName, cgf.convertType(expr->getType()), loc);
+  case NEON::BI__builtin_neon_vsrid_n_s64:
+  case NEON::BI__builtin_neon_vsrid_n_u64:
+    break;
   }
 
-  return nullptr;
+  // Generic handling based on TypeModifier flags, mirroring
+  // EmitCommonNeonSISDBuiltinExpr + LookupNeonLLVMIntrinsic in ARM.cpp.
+  //
+  // The TypeModifier encodes how the intrinsic's argument and return types
+  // relate to the builtin's scalar types. For SISD builtins the key flags
+  // are:
+  //   - VectorizeArgTypes: wrap each arg type into a fixed-width vector
+  //   - Use64BitVectors / Use128BitVectors: choose the vector width
+  //     (when neither is set the vector has 1 element)
+  //   - AddRetType / VectorizeRetType: analogous flags for the return type
+  //
+  // ARM.cpp doesn't need to know about specific builtins like
+  // `vsrid_n_{s,u}64` because it lets LLVM resolve the intrinsic's
+  // signature (via `CGM.getIntrinsic`) and then walks the resolved
+  // Function* formal parameter types. CIR has no LLVMContext here, so
+  // we derive the same argument/result types directly from the Clang
+  // operand types.
+
+  unsigned modifier = info.TypeModifier;
+  CIRGenBuilderTy &builder = cgf.getBuilder();
+  mlir::Type argTy = cgf.convertType(expr->getArg(0)->getType());
+  mlir::Type resultTy = cgf.convertType(expr->getType());
+
+  int vectorSize = 0;
+  if (modifier & Use64BitVectors)
+    vectorSize = 64;
+  else if (modifier & Use128BitVectors)
+    vectorSize = 128;
+
+  auto wrapAsVector = [&](mlir::Type ty) -> cir::VectorType {
+    unsigned bits = cgf.cgm.getDataLayout().getTypeSizeInBits(ty);
+    unsigned elts = vectorSize ? vectorSize / bits : 1;
+    return cir::VectorType::get(ty, elts);
+  };
+
+  // Determine the vectorized data type.
+  cir::VectorType vecArgTy;
+  if (modifier & VectorizeArgTypes)
+    vecArgTy = wrapAsVector(argTy);
+
+  // Determine the intrinsic result type: `VectorizeRetType` returns a
+  // vector; otherwise, if data args are vectorized and `AddRetType` is
+  // unset, use a vector return with the same shape as those args.
+  mlir::Type funcResTy = resultTy;
+  if (modifier & VectorizeRetType)
+    funcResTy = wrapAsVector(resultTy);
+  else if (vecArgTy && !(modifier & AddRetType))
+    funcResTy = wrapAsVector(resultTy);
+
+  // Build the arg types for `emitNeonCall`.
+  llvm::SmallVector<mlir::Type> argTypes;
+  argTypes.reserve(ops.size());
+  for (mlir::Value op : ops) {
+    if (vecArgTy && op.getType() == argTy)
+      argTypes.push_back(vecArgTy);
+    else
+      argTypes.push_back(op.getType());
+  }
+
+  // Promote each scalar operand to a vector if the intrinsic expects one.
+  for (unsigned j = 0; j < ops.size(); ++j) {
+    mlir::Type opTy = ops[j].getType();
+    mlir::Type expectedTy = argTypes[j];
+
+    if (auto expectedVecTy = mlir::dyn_cast<cir::VectorType>(expectedTy)) {
+      if (!mlir::isa<cir::VectorType>(opTy)) {
+        // The constant argument to an _n_ intrinsic always has i32 type, so
+        // truncate/cast it to the vector element type before forming the 
vector
+        // value.
+        mlir::Type eltTy = expectedVecTy.getElementType();
+        if (opTy != eltTy)
+          ops[j] = builder.createIntCast(ops[j], eltTy);
+        ops[j] = builder.createBitcast(ops[j], expectedVecTy);
+      }
+    }
+  }
+
+  mlir::Value result = emitNeonCall(cgf.cgm, builder, std::move(argTypes), ops,
+                                    llvmIntrName, funcResTy, loc);
+
+  // If the intrinsic returned a vector but the builtin is scalar, cast back.
+  if (result.getType() != resultTy)
+    result = builder.createBitcast(result, resultTy);
----------------
iamvickynguyen wrote:

Thank you! You're right! I've removed this.

https://github.com/llvm/llvm-project/pull/196776
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to