================
@@ -1705,16 +1705,21 @@ class CIRGenFunction : public CIRGenTypeCache {
void instantiateIndirectGotoBlock();
- /// Emit a simple LLVM intrinsic that takes N scalar arguments and whose
- /// return type matches the type of the first argument. The intrinsic name is
- /// used verbatim; any overload mangling (e.g. `.f32`, `.p1`) must be baked
- /// into \p intrinName by the caller.
+ /// Emit a simple LLVM intrinsic that takes N scalar arguments. The
intrinsic
+ /// name is used verbatim; any overload mangling (e.g. `.f32`, `.p1`) must be
+ /// baked into \p intrinName by the caller. The result type defaults to the
+ /// type of the first argument; pass \p resultType for intrinsics whose
result
+ /// differs from the operand, such as a vector reduction that returns the
+ /// element type. Unlike classic CodeGen, CIR has no intrinsic registry to
+ /// derive the result type from the operand, so it must be supplied here.
template <unsigned N>
[[maybe_unused]] RValue
emitBuiltinWithOneOverloadedType(const CallExpr *e,
- llvm::StringRef intrinName) {
+ llvm::StringRef intrinName,
+ mlir::Type resultType = {}) {
----------------
erichkeane wrote:
As I asked before, WHY was the `convertType` included (When it isn't in classic
codegen) and why was it also not OK for vector operations? Particularly when
you ARE passing the `convertType` of `e->getArg(0)` in the calls to this
function above?
https://github.com/llvm/llvm-project/pull/201164
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
