================
@@ -1602,12 +1514,40 @@ mlir::Value CIRGenFunction::emitX86BuiltinExpr(unsigned
builtinID,
case X86::BI__builtin_ia32_cmpnltsd:
case X86::BI__builtin_ia32_cmpnlesd:
case X86::BI__builtin_ia32_cmpordsd:
- case X86::BI__builtin_ia32_vcvtph2ps_mask:
- case X86::BI__builtin_ia32_vcvtph2ps256_mask:
- case X86::BI__builtin_ia32_vcvtph2ps512_mask:
- case X86::BI__builtin_ia32_cvtneps2bf16_128_mask:
- case X86::BI__builtin_ia32_cvtneps2bf16_256_mask:
- case X86::BI__builtin_ia32_cvtneps2bf16_512_mask:
+ cgm.errorNYI(expr->getSourceRange(),
+ std::string("unimplemented X86 builtin call: ") +
+ getContext().BuiltinInfo.getName(builtinID));
+ return {};
+ case X86::BI__builtin_ia32_vcvtph2ps_mask: {
+ mlir::Location loc = getLoc(expr->getExprLoc());
+ return emitIntrinsicCallOp(builder, loc, "x86.avx512.mask.vcvtph2ps.128",
+ convertType(expr->getType()), ops);
+ }
+ case X86::BI__builtin_ia32_vcvtph2ps256_mask: {
+ mlir::Location loc = getLoc(expr->getExprLoc());
+ return emitIntrinsicCallOp(builder, loc, "x86.avx512.mask.vcvtph2ps.256",
+ convertType(expr->getType()), ops);
+ }
+ case X86::BI__builtin_ia32_vcvtph2ps512_mask: {
+ mlir::Location loc = getLoc(expr->getExprLoc());
+ return emitIntrinsicCallOp(builder, loc, "x86.avx512.mask.vcvtph2ps.512",
+ convertType(expr->getType()), ops);
+ }
+ case X86::BI__builtin_ia32_cvtneps2bf16_128_mask: {
+ mlir::Location loc = getLoc(expr->getExprLoc());
+ return emitIntrinsicCallOp(builder, loc,
"x86.avx512bf16.mask.cvtneps2bf16.128",
+ convertType(expr->getType()), ops);
+ }
+ case X86::BI__builtin_ia32_cvtneps2bf16_256_mask: {
+ mlir::Location loc = getLoc(expr->getExprLoc());
+ return emitIntrinsicCallOp(builder, loc, "x86.avx512bf16.cvtneps2bf16.256",
+ convertType(expr->getType()), ops);
+ }
+ case X86::BI__builtin_ia32_cvtneps2bf16_512_mask: {
----------------
Priyanshu3820 wrote:
> > I too considered this way and I take it that it's your implementation of
> > the reduce intrinsics right? But I think we are supposed to follow the
> > already established pattern aren't we? I would be more than happy to
> > implement this way though.
>
> In general, we are trying to follow the established code patterns, but if the
> code can be improved it's OK to diverge. I like the suggestion from
> @badumbatish here.
updated
https://github.com/llvm/llvm-project/pull/171615
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
