================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
