================
@@ -257,6 +257,64 @@ static cir::VectorType
getNeonPairwiseWidenInputType(cir::VectorType resType,
return result;
}
+// Derive the LLVM intrinsic's per-operand argument types and its result
+// type for use when emitting the intrinsic call.
+//
+// `modifier` is the TypeModifier bitmask from `ARMVectorIntrinsicInfo`
+// (callers pass `info.TypeModifier`; see AArch64CodeGenUtils.h). It 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 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.
+static std::pair<mlir::Type, llvm::SmallVector<mlir::Type>>
+deriveNeonIntrinsicOperandTypes(CIRGenFunction &cgf, unsigned modifier,
+ mlir::Type argTy, mlir::Type resultTy,
+ llvm::ArrayRef<mlir::Value> ops) {
+ 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);
+
+ 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());
+ }
----------------
banach-space wrote:
In this block we assume that every argument for which the type matches `arg0Ty`
should be "vectorised" similarly to `arg0Ty`. I don't have a counter-example,
so this is fine with me. However, it would be good to document this assumption.
Also, `if ((modifier & VectorizeArgTypes vecArgTy) && op.getType() == argTy)`
would make the intent clearer (as opposed to `if (vecArgTy && op.getType() ==
argTy)`). Your current version is shorter, but given how convoluted this is, I
feel that being a bit more verbose might make things clearer for our future
selves :)
https://github.com/llvm/llvm-project/pull/196776
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
