[clang] [CIR][AArc64] Add lowering for fp16 intrinsics (step + rounding) (PR #207511)

[Andrzej Warzyński via cfe-commits]

================
@@ -2876,7 +2876,15 @@ CIRGenFunction::emitAArch64BuiltinExpr(unsigned builtinID, const CallExpr *expr,
   case NEON::BI__builtin_neon_vmaxnmh_f16:
   case NEON::BI__builtin_neon_vrecpss_f32:
   case NEON::BI__builtin_neon_vrecpsd_f64:
-  case NEON::BI__builtin_neon_vrecpsh_f16:
+    cgm.errorNYI(expr->getSourceRange(),
+                 std::string("unimplemented AArch64 builtin call: ") +
+                     getContext().BuiltinInfo.getName(builtinID));
+    return mlir::Value{};
+  case NEON::BI__builtin_neon_vrecpsh_f16: {
+    auto halfTy = builder.getFp16Ty();
+    return emitCallMaybeConstrainedBuiltin(builder, loc, "aarch64.neon.frecps",
----------------
banach-space wrote:

> Do FP constraints get applied to this builtin? 

Not to this one, no. Thanks for catching it!

> As we go forward with the new LLVM IR representation Nikita has proposed (https://discourse.llvm.org/t/rfc-yet-another-strict-fp/90798) and the corresponding MLIR representation I have proposed (https://discourse.llvm.org/t/rfc-mlir-new-representation-of-floating-point-constraints/91123), we should be able to attach rounding-mode and exception handling constraints to target-specific builtin calls, so even if emitCallMaybeConstrainedBuiltin doesn't do anything yet, it's probably still a good idea to start using it.

Thank you for pointing it out - I need to catch up with that thread.

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