================
@@ -2092,6 +2106,13 @@ CIRGenFunction::emitAArch64BuiltinExpr(unsigned
builtinID, const CallExpr *expr,
return mlir::Value{};
}
+ if (builtinID == NEON::BI__builtin_neon_vfmaq_f16) {
+ cgm.errorNYI(expr->getSourceRange(),
+ std::string("unimplemented AArch64 builtin call: ") +
+ getContext().BuiltinInfo.getName(builtinID));
+ return mlir::Value{};
+ }
+
----------------
yairbenavraham wrote:
If I understand correctly, this guard is needed because, again, if I understand
correctly, vfmaq_f16 is remapped by neonEquivalentIntrinsicMap to the same
canonical BI__builtin_neon_vfmaq_v path as the f32/f64 wrappers. Since this
patch only implements and adds CIR coverage for vfmaq_f32 and vfmaq_f64, the
guard prevents f16 from being enabled accidentally without CIR tests. I added
the guard to preserve that scope boundary, but I’m wondering whether I need to
have this PR vfmaq_f32 and vfmaq_f64 only (and then to remove the guard) or
keep it vfmaq_f32 and vfmaq_f64 but also make sure the vfmaq_f16 case is
guarded till it will be implemented.
https://github.com/llvm/llvm-project/pull/195602
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
