From 4fcf0004fa7b34566391fda00f7c40d1c1605a8b 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 llvm-svn: 364610 --- llvm/docs/LangRef.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 14d7d57..e7dd40a 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/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.7.4