From 17947255384dbaa060865e2c5481839f30c206df Mon Sep 17 00:00:00 2001 From: Amara Emerson Date: Thu, 27 Jun 2019 23:33:05 +0000 Subject: [PATCH] [LangRef] Clarify codegen expectations for intrinsics with fp/integer-only overloads. This change is a result of discussions on list: "GlobalISel: Ambiguous intrinsic semantics problem" Differential Revision: https://reviews.llvm.org/D59657 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364610 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LangRef.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/LangRef.rst b/docs/LangRef.rst index 14d7d57f19b..e7dd40af168 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -10480,6 +10480,16 @@ overloaded, and only one type suffix is required. Because the argument's type is matched against the return type, it does not require its own name suffix. +For target developers who are defining intrinsics for back-end code +generation, any intrinsic overloads based solely the distinction between +integer or floating point types should not be relied upon for correct +code generation. In such cases, the recommended approach for target +maintainers when defining intrinsics is to create separate integer and +FP intrinsics rather than rely on overloading. For example, if different +codegen is required for ``llvm.target.foo(<4 x i32>)`` and +``llvm.target.foo(<4 x float>)`` then these should be split into +different intrinsics. + To learn how to add an intrinsic function, please see the `Extending LLVM Guide `_. -- 2.40.0