================
@@ -1034,6 +1034,10 @@ Value *CodeGenFunction::EmitNVPTXBuiltinExpr(unsigned
BuiltinID,
case NVPTX::BI__nvvm_fmin_xorsign_abs_f16x2:
return MakeHalfType(Intrinsic::nvvm_fmin_xorsign_abs_f16x2, BuiltinID, E,
*this);
+ case NVPTX::BI__nvvm_abs_bf16:
+ case NVPTX::BI__nvvm_abs_bf16x2:
+ return Builder.CreateUnaryIntrinsic(Intrinsic::nvvm_fabs,
----------------
Artem-B wrote:
I do not think you need to do this. Builtin handling should've been plumbed
through by `ClangBuiltin` here:
https://github.com/llvm/llvm-project/blob/30d13e359190f7a0e2122292ec4a4fc1a6c71acc/llvm/include/llvm/IR/IntrinsicsNVVM.td#L1053
If overloadable intrinsics don't work well with table-gen-generated builtin
glue and do need special handling, then I would expect changes similar to these
would be needed for other builtins affected by your changes.
I'd start by checking if all those builtins that map to the new intrinsics are
covered by clang tests (probably not, as they would probably show up in the
tests along with bf16 variant) and that they do generate the calls to the
correct intrinsics, and based on the results adjust the builtin handling as
needed.
https://github.com/llvm/llvm-project/pull/135644
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
