Full conversion to standalone project + travis fixup #3

karolherbst · 2018-04-11T18:12:07Z

basically contains a complete rework of the CMake files, so that we can build the project without having to put it inside a llvm tree and build it there. A pkgconfig file is also added so that other projects can simply depend on LLVMSPIRVLib.
Travis was changed accordingly to be able to build and run the tests.

llvm-lit is a bit weirdly handled on each distribution. On Fedora I have a "python3-lit" package which provides a "lit" binary the build system uses. On Ubuntu you have to install llvm-X-tools and point LLVM_EXTERNAL_LIT to the correct lit.py file.

There were also some changes required to the lit files, so that lit doesn't try to create new directories in system paths.

Builds can be seen here until the project enables travis-ci:
https://travis-ci.org/karolherbst/SPIRV-LLVM-Translator

some Notes:

Also one of the tests are crashing when built with clang and not gcc.

CLAassistant · 2018-04-11T18:12:14Z

All committers have signed the CLA.

pierremoreau · 2018-04-12T07:23:52Z

You might want to disable clang in this pull request, and add it back once it is no longer crashing.

bader · 2018-04-12T08:36:03Z

.travis.yml

+      -DLLVM_EXTERNAL_LIT="/usr/lib/llvm-7/build/utils/lit/lit.py"
+      -DCMAKE_INSTALL_PREFIX=../install/
+      -G "Unix Makefiles"
+  - make && make test && make install


Does it make sense to add '-j 2' to speed up the build/testing?

yeah, we get indeed two cores on containers. I will add it as a global env var though.

bader · 2018-04-12T08:38:11Z

CMakeLists.txt

-CMAKE_MINIMUM_REQUIRED(VERSION 3.3)
+CMAKE_MINIMUM_REQUIRED(VERSION 3.1)
+
+INCLUDE(GNUInstallDirs)


I see that LLVM project uses lower case for cmake commands.
I think it make sense to follow LLVM notation in case we eventually contribute this project to LLVM.

bader · 2018-04-12T08:42:52Z

CMakeLists.txt

+SET(CMAKE_CXX_STANDARD 11)
+SET(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+FIND_PACKAGE(LLVM 7.0.0 REQUIRED)


I think we should look for installed LLVM only if we build out-of-tree. Could you add a check for that similar to how clang does it?

I could just copy what clang does, but I'm not quite sure if it's worth to care about it for now, because at least ll distributions packaging this wouldn't build it this way. And the normal user doesn't want to clone llvm just to build this tool either.

So for what kind of users would we want to support building it with llvm together?

For example for developers who already have llvm and clang sources cloned. They likely to have some modifications in clang or llvm sources. They as well may have custom installation directory. They might want to test how their changes in clang affect the translator. In this case it is easier to build and test everything at once.

bader · 2018-04-12T08:50:04Z

tools/llvm-spirv/CMakeLists.txt

-add_llvm_tool(llvm-spirv
-  llvm-spirv.cpp
-  )
+ADD_EXECUTABLE(llvm-spirv


Why not use add_llvm_tool function?

because it doesn't really work if used outside a full LLVM build

also it hardcodes "bin" as the install target and doesn't use GNUInstallDirs, which... is annoying.

pierremoreau · 2018-04-12T11:19:14Z

lib/SPIRV/CMakeLists.txt

-if ( SPIRV_USE_LLVM_API )
-  add_definitions(-D_SPIRV_LLVM_API)
+if(SPIRV_USE_LLVM_API)
+  ADD_DEFINITIONS(-D_SPIRV_LLVM_API)


This should be lowercase as well.

AlexeySotkin · 2018-04-12T13:32:59Z

.travis.yml

+    packages:
+    - llvm-7-tools
+    - llvm-7-dev
+    - python3


Do we really need python3 here ?

lit is written in python and I doubt the container image has python3 preinstalled... let me check

AlexeySotkin · 2018-04-12T13:40:35Z

.travis.yml

+addons:
+  apt:
+    sources:
+    - llvm-toolchain-trusty


It might be useful add a comment that it is an alias, and what exactly repository it adds.

AlexeySotkin · 2018-04-12T13:43:00Z

LLVMSPIRVLib.pc.in

+includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
+
+Name: LLVMSPIRVLib
+Description: LLVM/SPIR-V bi-direction translator


bi-directional

karolherbst · 2018-04-13T12:43:12Z

@AlexeySotkin @bader @pierremoreau
so I rewored the cmake files again and now it should be possible to build it both inside and outside an llvm tree. Currently I test the former and will adjust the travis-ci file so that we test both.

karolherbst · 2018-04-13T12:44:11Z

the ugly part about this is, that the install directories are set pretty statically with the llvm macros, but I think it might be fine until people complain about this.

v2: convert to lower case

karolherbst · 2018-04-13T19:17:56Z

@AlexeySotkin @bader @pierremoreau:
I think I am done now. It should be possible to build it from inside LLVM and from outside. I also adjusted the travis-ci to test both version, added the clang builds to be allowed to fail (allthough for weird reasons the test fails just for the out of tree build, maybe one of you have any ideas about that?)

As a bonus I also enabled build testing on Mac OS X with Xcode-9, sadly a bunch of tests seem to fail there.

AlexeySotkin · 2018-04-16T06:00:59Z

Looks good to me. Thanks Karol!

v2: add -j2 to make

karolherbst · 2018-04-16T10:41:29Z

@AlexeySotkin just noticed that I forgot to push my updated branch again. Just the travis-ci file changed though (remove the Xcode 7.3 stuff and fixed the allow_failures thing.

Remove duplicated values from OCLSPIRVBuiltinMap.

…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

…ias MD transla.. 'master' -> 'xmain-web' (KhronosGroup#3) CONFLICT (content): Merge conflict in lib/SPIRV/SPIRVWriter.cpp commit 2c61561 Author: Dmitry <[email protected]> Date: Tue Apr 13 19:18:52 2021 +0300 Tolerate more inputs during alias.scope/noalias MD translation (KhronosGroup#994) According to https://llvm.org/docs/LangRef.html aliasing metadata must have following layout: List { MD Node Scope1, (other scopes) ... } Scope1 { MD Node Scope1, MD Node Domain1, (optional MD String) } ... (other scopes) Domain1 { MD Node Domain1, (optional MD String) } ... (other domains) and this pattern is actually being checked in LLVM's ScopedNoAliasAA.cpp. But in a harsh reality LLVM opt have bugs, which can result in this pattern violation. So lets be more tolerant to the input IR module. Signed-off-by: Dmitry Sidorov <[email protected]> Change-Id: I6187c923481aba87a6a501c36d6dafe826a3039d

…nslation (KhronosGroup#1133) 'master' -> 'xmain-web' (KhronosGroup#3) CONFLICT (content): Merge conflict in lib/SPIRV/SPIRVInternal.h commit bafc886 Author: Yilong Guo <[email protected]> Date: Tue Aug 3 15:25:57 2021 +0800 [SPV-IR] Fix SPIRV builtin variable/call translation (KhronosGroup#1133) This PR fixes the translation of SPIRV builtin variables/calls. The translator now is able to recognize builtin-call-based SPV-IR input. e.g. `call spir_func i64 @_Z33__spirv_BuiltinGlobalInvocationIdi(i32 1)` ### LLVM --> SPIRV translation: We first translate OCL work item builtins to SPV-IR builtin calls in `OCLToSPIRV`. For example: `@_Z13get_global_idj(i) -> @_Z33__spirv_BuiltinGlobalInvocationIdi(i)` SPV-IR builtin calls are transformed to variables in `LLVMToSPIRV`. This step is shared by all source inputs (SPV-IR, OCL-IR). For example: `@_Z33__spirv_BuiltinGlobalInvocationIdi(i) -> x = load GlobalInvocationId; extract x, i` ### SPIRV --> LLVM translation: We lower SPIRV builtin variables into calls in `SPIRVToLLVM` so that SPV-IR has builtin function calls (instead of variables) by default. Builtin calls in SPV-IR can be then translated into OpenCL builtin calls, in `SPIRVToOCL`. e.g. `@_Z33__spirv_BuiltinGlobalInvocationIdi(i) -> @_Z13get_global_idj(i)` `SPIRVToOCL` is also capable of lower SPIRV builtin variables into calls as preprocessing, so that this pass can be used by users independently to translate SPV-IR into OCL-IR. Signed-off-by: Yilong Guo [email protected] Change-Id: Ie361b71607ba37677d7634f33f55e7286cee673f

…1145) 'master' -> 'xmain-web' (KhronosGroup#3) CONFLICT (content): Merge conflict in lib/SPIRV/SPIRVInternal.h commit a6ca745 Author: Mariya Podchishchaeva <[email protected]> Date: Fri Aug 6 16:48:57 2021 +0300 Fix SPV-IR for OpBuildNDRange (KhronosGroup#1145) It is translated to a function with unmangled name __spirv_BuildNDRange_{1|2|3}D with struct return parameter and array arguments, since translator only translates it properly to SPIR-V with this signature. _ND postfix is requred because array arguments are mangled in the same way, so if there was no postfix, translator would produce functions with same name for different dimensions. Change-Id: Ic74ab60b5186b28e30793d9ecea58f17e8bec8b6

… related metho.. 'master' -> 'xmain-web' (KhronosGroup#3) CONFLICT (content): Merge conflict in lib/SPIRV/SPIRVWriter.cpp CONFLICT (content): Merge conflict in lib/SPIRV/SPIRVReader.cpp CONFLICT (content): Merge conflict in lib/SPIRV/PreprocessMetadata.cpp commit 6eb3848 Author: KornevNikita <[email protected]> Date: Mon Sep 6 13:38:24 2021 +0300 Replace add-, get-, has-, removeAttribute by related methods. (KhronosGroup#1197) Change-Id: Iba0867f08b2c6f3a48e5924bbdffa07e9a6ddbfe

…f no FPGA decorations fou.. '"xmain"' -> '"xmain-web"' (KhronosGroup#3) CONFLICT (content): Merge conflict in test/transcoding/annotate_attribute.ll commit a15d232 Author: Dmitry Sidorov <[email protected]> Date: Wed Sep 15 10:21:15 2021 +0300 Enforce UserSemantic decoration if no FPGA decorations found (#1) Change-Id: I09ced3ba5ca03ac196c6dc87f3cbc0e63b74a01d Signed-off-by: Dmitry Sidorov <[email protected]> Co-authored-by: iclsrc <[email protected]> Co-authored-by: Sebastian Peryt <[email protected]>

…oration if no FPGA decorations fou.. '"xmain"' -> '"xmain-web"' (KhronosGroup#3) CONFLICT (content): Merge conflict in test/transcoding/annotate_attribute.ll commit a15d232 Author: Dmitry Sidorov <[email protected]> Date: Wed Sep 15 10:21:15 2021 +0300 Enforce UserSemantic decoration if no FPGA decorations found (#1) Change-Id: I09ced3ba5ca03ac196c6dc87f3cbc0e63b74a01d Signed-off-by: Dmitry Sidorov <[email protected]> Co-authored-by: iclsrc <[email protected]> Co-authored-by: Sebastian Peryt <[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 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

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

karolherbst force-pushed the travis branch 4 times, most recently from 538fcf5 to 7dcd254 Compare April 11, 2018 21:07

bader reviewed Apr 12, 2018

View reviewed changes

karolherbst force-pushed the travis branch from 7dcd254 to da88361 Compare April 12, 2018 10:18

pierremoreau reviewed Apr 12, 2018

View reviewed changes

karolherbst force-pushed the travis branch from da88361 to a557824 Compare April 12, 2018 11:42

karolherbst changed the title ~~Fully conversion to standalone project + travis fixup~~ Full conversion to standalone project + travis fixup Apr 12, 2018

AlexeySotkin reviewed Apr 12, 2018

View reviewed changes

karolherbst force-pushed the travis branch 2 times, most recently from 44c36a3 to 5f78d7a Compare April 13, 2018 12:42

cmake: rework to be able to build outside LLVM

a21f0b7

v2: convert to lower case

karolherbst force-pushed the travis branch from 5f78d7a to b2a94c5 Compare April 13, 2018 15:56

travis: make it build again

c5ef383

v2: add -j2 to make

karolherbst force-pushed the travis branch from b2a94c5 to c5ef383 Compare April 16, 2018 10:40

AlexeySotkin merged commit 4d2a651 into KhronosGroup:master Apr 16, 2018

davidrohr mentioned this pull request Feb 20, 2020

__builtin_popcount yields Unexpected llvm intrinsic #441

Closed

AnastasiaStulova mentioned this pull request Mar 26, 2020

Translation of BIFs from different frontends #206

Open

aratajew pushed a commit to aratajew/SPIRV-LLVM-Translator that referenced this pull request Apr 21, 2020

Merge pull request KhronosGroup#3 from aratajew/fix_dupl_in_map

23db7e9

Remove duplicated values from OCLSPIRVBuiltinMap.

vmaksimo pushed a commit to vmaksimo/SPIRV-LLVM-Translator that referenced this pull request Sep 1, 2022

Merge from 'xmain' to 'xmain-web' (KhronosGroup#3)

ec398c0

vmaksimo pushed a commit to vmaksimo/SPIRV-LLVM-Translator that referenced this pull request Sep 1, 2022

Merge from 'master' to 'xmain-web' (KhronosGroup#3)

fb44e92

vmaksimo pushed a commit to vmaksimo/SPIRV-LLVM-Translator that referenced this pull request Sep 1, 2022

Merge from 'master' to 'xmain-web' (KhronosGroup#3)

9c77e77

vmaksimo pushed a commit to vmaksimo/SPIRV-LLVM-Translator that referenced this pull request Sep 1, 2022

Merge from 'master' to 'xmain-web' (KhronosGroup#3)

215d7ba

vmaksimo pushed a commit to vmaksimo/SPIRV-LLVM-Translator that referenced this pull request Sep 1, 2022

Merge from 'xmain' to 'xmain-web' (KhronosGroup#3)

41ce55e

asudarsa mentioned this pull request Jul 13, 2023

[SPIR-V Extension] fpbuiltin-max-error support #2056

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 17] fpbuiltin-max-error support #2402

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 16] fpbuiltin-max-error support #2403

Merged

MiloszSkobejko mentioned this pull request Mar 5, 2024

[Backport to 15] fpbuiltin-max-error support #2407

Merged

MiloszSkobejko mentioned this pull request Mar 11, 2024

[Backport to 14] fpbuiltin-max-error support #2421

Merged

svenvh mentioned this pull request Dec 4, 2024

NO_INSTALL_RPATH breaks in-tree builds with shared libs #2906

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Full conversion to standalone project + travis fixup #3

Full conversion to standalone project + travis fixup #3

karolherbst commented Apr 11, 2018 •

edited

Loading

CLAassistant commented Apr 11, 2018 •

edited

Loading

pierremoreau commented Apr 12, 2018

bader Apr 12, 2018

karolherbst Apr 12, 2018

bader Apr 12, 2018

bader Apr 12, 2018

karolherbst Apr 12, 2018

AlexeySotkin Apr 12, 2018

bader Apr 12, 2018

karolherbst Apr 12, 2018

karolherbst Apr 12, 2018

pierremoreau Apr 12, 2018

AlexeySotkin Apr 12, 2018

karolherbst Apr 12, 2018

AlexeySotkin Apr 12, 2018

AlexeySotkin Apr 12, 2018

karolherbst commented Apr 13, 2018

karolherbst commented Apr 13, 2018

karolherbst commented Apr 13, 2018

AlexeySotkin commented Apr 16, 2018

karolherbst commented Apr 16, 2018

Full conversion to standalone project + travis fixup #3

Full conversion to standalone project + travis fixup #3

Conversation

karolherbst commented Apr 11, 2018 • edited Loading

CLAassistant commented Apr 11, 2018 • edited Loading

pierremoreau commented Apr 12, 2018

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

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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karolherbst commented Apr 13, 2018

karolherbst commented Apr 13, 2018

karolherbst commented Apr 13, 2018

AlexeySotkin commented Apr 16, 2018

karolherbst commented Apr 16, 2018

karolherbst commented Apr 11, 2018 •

edited

Loading

CLAassistant commented Apr 11, 2018 •

edited

Loading