Fix group_ops test

…Oct 2021):

   * update KhronosGroup#1:
     * this is now based off the official LLVM git repository (at a slightly older 13.0 commit, but I will rebase on top of the release branch once everything works)
     * I manually went over *all* modifications that I've made thus far, either taking them as-is, clean them up, rewrite them or remove some altogether -> this should be a good base for the future
     * all libfloor specific LLVM backend passes have been migrated to their own LLVM lib (LLVMLibFloor) + they are now licensed under GPL2 where applicable
     * the Host-Compute/CPU, CUDA and Metal backends should be fully functional already (all examples, test and other code compiles and works for these backends), while OpenCL and Vulkan are not supported yet (still need to migrate all SPIR-V changes and fix up various OpenCL things)
     * the LLVM 3.2 bitcode writer has been updated, but is not fully functional yet
     * the LLVM 3.5 bitcode writer has been removed, since there no longer is a target backend that uses it
     * the LLVM 5.0 bitcode writer has been fully updated and should be fully functional (used by the Metal backend)
     * all backends are now compiled in C++2b mode
     * added initial LibFloorGPUTargetMachine/LibFloorGPUSubTarget/LibFloorGPUTargetLowering implementations that can now be used to set/enable/handle GPU specific options (e.g. right now, this fixes vectorization to vector lengths that are not supported or don't make sense for performance reasons)
     * this now integrates/uses the Khronos SPIR-V LLVM translator (https://github.com/KhronosGroup/SPIRV-LLVM-Translator.git) as an LLVM (sub)project instead of the old directly integrated LLVM target library (I've only modified this to make it compatible with my LLVM changes thus far, no SPIR-V backend modifications from the old toolchain have been migrated yet)
     * CUDAImage: all image write PTX/ASM emission has now been integrated into this pass, instead of doing this on the library side (i.e. format handling via run-time switch)
     * MetalFinal: added initial handling/translation of LLVM intrinsics that have been added in recent versions (abs/*min/*max/minnum/maxnum), vector reduce intrinsics will emit an error for now
     * metallib-dis: improved error handling (will now actually print bitcode errors)
     * NOTE: since clang/LLVM/libc++ now reside in a mono repo, there now only is a single .patch file for all of them
     * NOTE: since the SPIR-V backend/translator is now its own repository, there is a .patch file for it now
     * NOTE: this still uses the old pass manager, I still need to migrate everything to the new one
     * NOTE: this brings C++20 support up to par with the minimum C++20 requirements for libfloor -> all code that is used by both host and device code can and will be updated to C++20 as well now (once everything is fully functional and the 8.0 toolchain has been removed)
     * NOTE: all clang/LLVM code is compiled in C++20 mode (instead of C++14 or C++17), an appropriate compiler is required to compile this
     * NOTE: now compiles with support for the AArch64 LLVM target (while Host-Compute does not support ARM device code yet, I might add this in the future)
     * NOTE: now uses clang as the default compiler on Linux (gcc is still supported for now, but I might drop support for it in the future)
     * NOTE: SPIRV-Tools have not been updated (still at the same version as the 8.0 toolchain)
   * update KhronosGroup#2:
     * migrated all Vulkan/SPIR-V modifications to the "latest" SPIRV-LLVM-Translator code
     * various Vulkan/SPIR-V adjustments for changes in LLVM and SPIRV-LLVM-Translator
     * LLVM/SPIR: move opencl_global_device/opencl_global_host address spaces to 100+
     * hard disable "-fconvergent-functions"/ConvergentFunctions, we don't want this to be on by default
     * libc++: added include/__config_site (we need a proper config file to use libc++)
     * SPIRFinal: allow int bit-width 1 (bool) + fixup byval
     * VulkanFinal: remove the select instruction workaround, this is no longer needed with SPIR-V 1.5
     * VulkanImage: extend image array handle loading to deal with more in-between bitcasts and inttoptr
     * LoopUnrollPass: changed pragma default threshold to max-uint, this should always consider an explicit request
     * NOTE: Vulkan/SPIR-V should now be fully functional and at feature parity with the 8.0 toolchain
     * NOTE: both the OpenCL/SPIR and the OpenCL/SPIR-V backends have not been migrated or tested yet (still TODO)
   * update KhronosGroup#3: integrated dxil-spirv CFG structurizer to gain major Vulkan CFG structurization improvements + various other Vulkan/SPIR-V improvements/fixes:
     * integrated and adopted the dxil-spirv CFG structurizer for use in LLVM (https://github.com/HansKristian-Work/dxil-spirv @189cc855b471591763d9951d63e51c72649037ab)
     * this structurizer is now used instead of the old one, which will be removed soon
     * the dxil-spirv CFG structurizer provides major improvements over the old CFG structurization and makes it possible to properly structurize almost all code
     * in cases where this still fails, a standard LLVM CFG structurization pass can now be run prior to the actual structurization (via -Xclang -vulkan-llvm-pre-structurization-pass) -> this can itself however transform the CFG into an unstructured form that can not be recovered by the dxil-spirv CFG structurizer
     * changed/added/removed passes prior to Vulkan CFG structurization+finalization: no longer run the LowerSwitchPass pass (switches can actually be handled now + this hurts more than it benefits), always run all GEP cleanup passes now, run FixIrreduciblePass + UnifyLoopExitsPass now
     * LLVM IR: allow unlimited name lengths by default now
     * VectorCombinePass: disable load insert vectorization when using Vulkan
     * AggressiveDCEPass: added an option to disable CFG removal (enabled for Vulkan after CFG structurization)
     * InstructionCombining/NewGVN: added Vulkan specific handling to disable the removal of fake continue BBs (even though these are unreachable, they are needed for "correctness")
     * AddressSpaceFix: can now handle PHI nodes
     * LLVMToSPIRVTransformations: don't allow undef values in PHI nodes -> replace them with zero vals
     * LLVMToSPIRVTransformations: now allows suffixes on floor.*_block placeholder calls
     * OCLToSPIRV: allow floating point types in atomic in Vulkan/GLSL mode
     * OCLToSPIRV/SPIRVWriter/SPIRV*: implemented initial handling/emission of floating point atomics in Vulkan/GLSL mode (handles fp atomic add) + sets SPV_EXT_shader_atomic_float_add, CapabilityAtomicFloat32AddEXT, CapabilityAtomicFloat64AddEXT when these are used
     * OCLToSPIRV: fixup handling of StorageBuffer storage class when using atomics
     * SPIRVWriter: full 8-bit and 16-bit integer type handling is required now -> set CapabilityInt8 and CapabilityInt16 when these are emitted
     * SPIRVWriter: fixed handling of unary instructions (fneg works again now)
     * SPIRVWriter: ensure that only unique incoming values+blocks are emitted in SPIR-V PHI nodes (on the LLVM side these may not be unique!)
     * SPIRVWriter: in Vulkan/GLSL mode, only use PtrAccessChain for pointers to the Workgroup/StorageBuffer/PhysicalStorageBuffer storage classes, otherwise use AccessChain
     * SPIRVWriter: handle memcpy in Vulkan/GLSL mode when a full object copy is performed
     * SPIRVWriter: better handling of floor.* builtin functions (prevents weird FP contract handling)
     * SPIRVWriter: fixed entry point / input var handling in Vulkan/GLSL mode
     * SPIR-V: CapabilityInt8 does not depend on CapabilityKernel (this is used in Shader mode as well)
     * SPIR-V: fixed 8-bit and 16-bit signed integer constant handling (sign-extend them when they are negative)
     * SPIR-V: properly set CapabilityFloat16 and never set CapabilityFloat16Buffer in Vulkan/GLSL mode
     * NOTE: in my testing, the dxil-spirv structurizer only failed in one case, for which however the new LLVM pre-pass option can be used now -> I no longer have any code that can not be structurized!
   * update KhronosGroup#4: OpenCL SPIR and SPIR-V are now functional in the new toolchain:
     * updated LLVM 3.2 bitcode writer
     * SPIR-V: disable all "enableAllExtensions()" calls, this is just a very bad idea
     * fixed OpenCL 2.1 and 2.2 version handling
   * update KhronosGroup#5: rebase on top of SPIRV-LLVM-Translator master @89ecd253a090b62b18add26ebdd610ac62186dba

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 <arvind.sudarsanam@intel.com>

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" }

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" }

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" }

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" }

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" }

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" }

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" }

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" }

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" }

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" }

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" }

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" }