Add new intrinsics and attributes to control accuracy of FP calls #8134

andykaylor · 2023-01-27T20:07:16Z

This patch adds a new set of fpbuiltin intrinsics to represent operations that are equivalent to common math library functions and basic operations, and adds a new call site attribute ("fp-max-error") to specify the required accuracy of these calls.

The purpose of these new IR constructs is to support alternate math library implementations and provide a general mechanism for selecting among multiple implementations based on specific requirements.

This patch adds a new set of fpbuiltin intrinsics to represent operations that are equivalent to common math library functions and basic operations, and adds a new call site attribute ("fp-max-error") to specify the required accuracy of these calls. The purpose of these new IR constructs is to support alternate math library implementations and provide a general mechanism for selecting among multiple implementations based on specific requirements.

bader

LGTM, just a couple of style nits.

llvm/lib/IR/IntrinsicInst.cpp

bader · 2023-01-27T23:31:31Z

llvm/include/llvm/IR/IntrinsicInst.h

+  static const std::string FPBUILTIN_PREFIX;
+  static const std::string FP_MAX_ERROR;


Shouldn't corresponding standard library header be included?

Do you mean ? It's included indirectly by ADT/StringSet.h. Do you want it to be included here explicitly?

Do you mean ? It's included indirectly by ADT/StringSet.h. Do you want it to be included here explicitly?

I think it makes code less sensitive to changes in llvm header files.
I see that the build passes in pre-commit, so adding #include <string> is optional.

llvm/lib/CodeGen/FPBuiltinFnSelection.cpp

bader · 2023-01-28T02:03:58Z

@andykaylor, could you take a look at failed lit test, please?

andykaylor · 2023-01-30T17:37:15Z

@andykaylor, could you take a look at failed lit test, please?

Yes, I will fix that today. The changes I merged were based on previous testing with llvm.org, and I guess I missed testing the AMDGPU case when preparing this PR.

asudarsa · 2023-02-01T15:00:15Z

llvm/docs/LangRef.rst

+identifiers are considered reserved for use with fpbuiltin intrinsics.
+
+No transformation should be performed on any fpbuiltin intrinsic if the
+intrinsic has any callsite attributes begining with "fpbuiltin-" that that code


Minor typo - "that that" -> "that the"

asudarsa · 2023-02-01T15:00:58Z

llvm/docs/LangRef.rst

+performing the transformation does not recognize.
+
+Unless otherwise specified using callsite attributes, the fpbuiltin intrinsics
+do not set ``errno`` or and may be assumed not to trap or raise floating-point


Please check this statement. Thanks

I'll update the statement. What I meant to convey is that the functions shouldn't be assumed to properly maintain the floating point exception state. What I have here doesn't accurately capture that.

asudarsa · 2023-02-01T15:06:32Z

llvm/include/llvm/Analysis/AltMathLibFuncs.def

+//
+//===----------------------------------------------------------------------===//
+
+// This .def file will create descriptions of available fpbuilt math library


minor typo fpbuilt -> fpbuiltin

asudarsa · 2023-02-01T15:21:59Z

llvm/include/llvm/IR/IntrinsicInst.h

+class FPBuiltinIntrinsic : public IntrinsicInst {
+public:
+  static const std::string FPBUILTIN_PREFIX;
+  static const std::string FP_MAX_ERROR;


Nit: Should we call this FPBUILTIN_MAX_ERROR just to be in sync with attribute name?

asudarsa · 2023-02-01T16:13:43Z

llvm/lib/Analysis/TargetLibraryInfo.cpp

+  if (I->IntrinID != Builtin->getIntrinsicID() ||
+      I->BaseFPType != Builtin->getBaseTypeID() ||
+      I->Accuracy > Builtin->getRequiredAccuracy().value())
+    return StringRef(); // TODO: Report fatal error?


We can return a fatal error. But it will also be useful to inform the user about best possible option when reporting the error. Thanks

I was leaning toward the opinion that it's best not to report any errors here and let the caller (in this case FPBuiltinFnSelectionPass) decide what to do with that, but this is the only place that we'll have the information about the closest match. The whole topic of error handling for these intrinsics probably needs to be reworked. I'd prefer to defer the decision for now.

asudarsa · 2023-02-01T16:21:53Z

llvm/lib/CodeGen/FPBuiltinFnSelection.cpp

+
+#define DEBUG_TYPE "fpbuiltin-fn-selection"
+
+static bool replaceWithAltMathFunction(FPBuiltinIntrinsic &BuiltinCall,


Just to understand, are we going to lose all fpbuiltin- attributes in this transformation? Thanks

Yes, that is my intention. After an implementation has been selected, the function being called should meet the specified requirements and should not be replaced. If we kept the attributes, it would mean that later passes (specifically instruction selection) would need to know what to do with them.

asudarsa

Minor nits. But LGTM overall. Thanks for the PR.

bader · 2023-02-01T22:55:36Z

@andykaylor, please, resolve merge conflicts.

andykaylor · 2023-02-03T20:52:03Z

@andykaylor - Is the failure in post-commit (see https://github.com/intel/llvm/actions/runs/4081102971/jobs/7034196473) related to this?

Yes, it does seem to be caused by this. I didn't see that locally. I'll try to figure out what's going on.

It happens if you build the compiler with clang instead of gcc.

Thanks. I can reproduce it now. I'll post a fix shortly.

andykaylor · 2023-02-03T20:58:58Z

The post-commit issue should be fixed by PR #8200.

hdelan · 2023-02-08T10:33:42Z

Hi @andykaylor thanks for all this work. We look forward to be able to use this in DPC++. In your RFC you suggested that the fp-max-error attribute could be set using a pragma or a global compile time flag. We think that perhaps a function attribute would be more fitting for SYCL, or perhaps introducing new SYCL experimental math funcs.

Are there any plans for the math lib? ie what is the status on implementing a generic cos func to a low ULP? In DPC++ we use libclc as a shim bc library to redirect to native math funcs. What lib will hold these generic high/low ULP func implementations?

pjaaskel

Thanks for working on this. Has anyone considered the SPIR-V story around this? Is the intention to transfer the attribute down to a SPIR-V or assume there are SPIR-V builtins that are selected before converting to SPIR-V?

pjaaskel · 2023-04-13T08:43:13Z

llvm/docs/LangRef.rst

+    implementations which are known to provide at least the accuracy described.
+    An implementation which is more accurate than required by this attribute
+    may be used.
+


Can we add explicit rounding modes as attributes? This would be to support CUDA/HIP intrinsics inputs: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#intrinsic-functions . The CUDA Programming Guide (like OpenCL for relaxed math) defines different error tolerance for different input ranges (see intrinsics starting from logf). Can we somehow encode this info here without resorting to worst case error tolerance?

@andykaylor

This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" } Signed-off-by: Arvind Sudarsanam <[email protected]>

@andykaylor

This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 #8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" } Signed-off-by: Arvind Sudarsanam <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@c6fe12b

@andykaylor

Changes were cherry-picked from the following commit: KhronosGroup@c6fe12b This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: KhronosGroup@c6fe12b Also added fixes from: KhronosGroup#2208 KhronosGroup#2192 This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: KhronosGroup@c6fe12b Also cherry picked fixes from: KhronosGroup#2208 KhronosGroup#2192 This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b Also cherry-picked fixes from: This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b Also cherry picked fixes from: This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) KhronosGroup#2 attributes KhronosGroup#2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) KhronosGroup#3 attributes KhronosGroup#3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b Also cherry-picked fixes from: This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b Also cherry picked fixes from: #2208 #2192 This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" }

@andykaylor

Changes were cherry-picked from the following commit: c6fe12b Also cherry picked fixes from: This changes add SPIR-V translator support for the SPIR-V extension documented here: KhronosGroup/SPIRV-Registry#193. This extension adds one decoration to represent maximum error for FP operations and adds the related Capability. SPIRV Headers support for representing this in SPIR-V: KhronosGroup/SPIRV-Headers#363 intel/llvm#8134 added a new call-site attribute associated with FP builtin intrinsics. This attribute is named 'fpbuiltin-max-error'. Following example shows how this extension is supported in the translator. The input LLVM IR uses new LLVM builtin calls to represent FP operations. An attribute named 'fpbuiltin-max-error' is used to represent the max-error allowed in the FP operation. Example Input LLVM: %t6 = call float @llvm.fpbuiltin.sin.f32(float %f1) #2 attributes #2 = { "fpbuiltin-max-error"="2.5" } This is translated into a SPIR-V instruction (for add/sub/mul/div/rem) and OpenCl extended instruction for other instructions. A decoration to represent the max-error is attached to the SPIR-V instruction. SPIR-V code: 4 Decorate 97 FPMaxErrorDecorationINTEL 1075838976 6 ExtInst 2 97 1 sin 88 No new support is added to support translating this SPIR_V back to LLVM. Existing support is used. The decoration is translated back into named metadata associated with the LLVM instruction. This can be readily consumed by backends. Based on input from @andykaylor, we emit attributes when the FP operation is translated back to a call to a builtin function and emit metadata otherwise. Translated LLVM code for basic math functions (add/sub/mul/div/rem): %t6 = fmul float %f1, %f2, !fpbuiltin-max-error !7 !7 = !{!"2.500000"} Translated LLVM code for other math functions: %t6 = call spir_func float @_Z3sinf(float %f1) #3 attributes #3 = { "fpbuiltin-max-error"="4.000000" }

In intel#8134, a new pass was added and many pipeline tests were updated to account for this, but not all, and some of the ones that were added were inadvertently removed again in later LLVM pulldowns.

In #8134, a new pass was added and many pipeline tests were updated to account for this, but not all, and some of the ones that were added were inadvertently removed again in later LLVM pulldowns.

andykaylor requested a review from a team as a code owner January 27, 2023 20:07

andykaylor temporarily deployed to aws January 27, 2023 20:51 — with GitHub Actions Inactive

andykaylor requested review from asudarsa, bader and jinge90 January 27, 2023 21:55

bader approved these changes Jan 28, 2023

View reviewed changes

Fix AMDGPU pipeline test

74fd8ec

andykaylor temporarily deployed to aws January 31, 2023 00:20 — with GitHub Actions Inactive

andykaylor temporarily deployed to aws January 31, 2023 00:52 — with GitHub Actions Inactive

Address review comments

6b0f579

andykaylor temporarily deployed to aws February 1, 2023 01:34 — with GitHub Actions Inactive

andykaylor temporarily deployed to aws February 1, 2023 02:11 — with GitHub Actions Inactive

asudarsa reviewed Feb 1, 2023

View reviewed changes

asudarsa approved these changes Feb 1, 2023

View reviewed changes

More changes to address review feedback

a2f2ab6

andykaylor temporarily deployed to aws February 1, 2023 23:48 — with GitHub Actions Inactive

Merge branch 'sycl' into fp-accuracy

c61bc99

andykaylor added the disable-lint Skip linter check step and proceed with build jobs label Feb 2, 2023

clang-format fixes

d06738a

andykaylor temporarily deployed to aws February 2, 2023 18:51 — with GitHub Actions Inactive

Fix a trailing whitespace issue

eabaf18

andykaylor mentioned this pull request Feb 9, 2023

[SYCL][FE][Driver] Implement floating point accuracy control #8280

Merged

pjaaskel reviewed Apr 13, 2023

View reviewed changes

asudarsa mentioned this pull request Jun 9, 2023

Add support for fp_max_error extension KhronosGroup/SPIRV-Headers#348

Merged

asudarsa mentioned this pull request Jun 19, 2023

[SPIR-V Extension] fpbuiltin-max-error support KhronosGroup/SPIRV-LLVM-Translator#2056

Merged

bader mentioned this pull request Sep 14, 2023

LLVM and SPIRV-LLVM-Translator pulldown (WW37) #11185

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 17] fpbuiltin-max-error support KhronosGroup/SPIRV-LLVM-Translator#2402

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 16] fpbuiltin-max-error support KhronosGroup/SPIRV-LLVM-Translator#2403

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 15] fpbuiltin-max-error support KhronosGroup/SPIRV-LLVM-Translator#2407

Merged

MiloszSkobejko mentioned this pull request Mar 11, 2024

[Backport to 14] fpbuiltin-max-error support KhronosGroup/SPIRV-LLVM-Translator#2421

Merged

hvdijk mentioned this pull request Apr 9, 2025

Fix pipeline tests. #17940

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add new intrinsics and attributes to control accuracy of FP calls #8134

Add new intrinsics and attributes to control accuracy of FP calls #8134

andykaylor commented Jan 27, 2023

bader left a comment

bader Jan 27, 2023

andykaylor Feb 1, 2023

bader Feb 1, 2023

bader commented Jan 28, 2023

andykaylor commented Jan 30, 2023

asudarsa Feb 1, 2023

asudarsa Feb 1, 2023

andykaylor Feb 1, 2023

asudarsa Feb 1, 2023

asudarsa Feb 1, 2023 •

edited

Loading

asudarsa Feb 1, 2023

andykaylor Feb 1, 2023

asudarsa Feb 1, 2023 •

edited

Loading

andykaylor Feb 1, 2023

asudarsa left a comment

bader commented Feb 1, 2023

andykaylor commented Feb 3, 2023

andykaylor commented Feb 3, 2023

hdelan commented Feb 8, 2023

pjaaskel left a comment

pjaaskel Apr 13, 2023

		static const std::string FPBUILTIN_PREFIX;
		static const std::string FP_MAX_ERROR;


		#define DEBUG_TYPE "fpbuiltin-fn-selection"

		static bool replaceWithAltMathFunction(FPBuiltinIntrinsic &BuiltinCall,

Add new intrinsics and attributes to control accuracy of FP calls #8134

Add new intrinsics and attributes to control accuracy of FP calls #8134

Conversation

andykaylor commented Jan 27, 2023

bader left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bader commented Jan 28, 2023

andykaylor commented Jan 30, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

asudarsa Feb 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

asudarsa Feb 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

asudarsa left a comment

Choose a reason for hiding this comment

bader commented Feb 1, 2023

andykaylor commented Feb 3, 2023

andykaylor commented Feb 3, 2023

hdelan commented Feb 8, 2023

pjaaskel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

asudarsa Feb 1, 2023 •

edited

Loading

asudarsa Feb 1, 2023 •

edited

Loading