[clang] [CIR] Lower bitwise vector reduce builtins (PR #201164)

[Erich Keane via cfe-commits]

================
@@ -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