Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2. The application developer ships the application containing the SPIR-V binary to customers. 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. Location>From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter:1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V. 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. Implementation About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. The current implementation uses a shared in-memory representation of SPIR-V, which facilitates supporting bi-way translation. The round-trip translated LLVM IR by the current implementation has passed OpenCL SPIR 1.2 conformance test, which proves the current implementation works. On the other hand, the SelectionDAG/MC approach would require significant tweaking compared to a conventional backend, since SPIR-V is not a low level machine ISA but a high level generic IR. Also, the SelectionDAG/MC approach only supports one-way translation from LLVM to SPIR-V. Therefore unless major concern arises, we will keep the current implementation approach. Maintenance The current implementation works by breaking down LLVM IR to instructions and re-constructing them in SPIR-V, and vice versa. Therefore the dependence of the current implementation on LLVM is mainly the C++ API in llvm/include/IR. As such, its dependence on LLVM is similar to typical module passes. Our experience with porting it among LLVM 3.2/3.4/3.6 is that the porting effort is moderate. Milestones Currently Clang can compile OpenCL 1.2/2.0 C kernel source to LLVM IR with spir/spir64 target triple, which is compatible with SPIR-V for the supported instructions, data types and builtin functions. Therefore the first milestone of the converter is to support compiling OpenCL 1.2/2.0 kernel to SPIR-V. This is also to lay the foundation for the upcoming OpenCL 2.1 C++ frontend development in Clang. The next milestone would be supporting OpenCL 2.1 C++, which hopefully would be in synch with the frontend development work. In the meantime, as the SPIR-V target becomes stable and is able to support the instructions common to OpenCL and GLSL, hopefully the GLSL frontend work and support for GLSL specific instructions would pick up and finally we would have a SPIR-V target supporting the complete SPIR-V spec. Testing We will add lit tests for SPIR-V. Also the converter would be tested by different OpenCL vendors for production quality through comprehensive conformance tests, since SPIR-V is required by OpenCL 2.1. Logistics AMD, Intel and some other SPIR WG members would join force for the development of the bi-way converter. Since supporting of SPIR-V is required by OpenCL 2.1, it is expected that OpenCL vendors would continue the maintenance efforts for supporting SPIRV target in LLVM. Yaxun Liu AMD -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/a64ea91f/attachment.html>
Hi Liu, Thanks for the detailed proposal.> On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. > > Proposal of Adding SPIRV Target > > Background > > SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: > > 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. > 2. The application developer ships the application containing the SPIR-V binary to customers. > 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. > 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device.Step 4 of your “typical use case” includes "changes the target triple and data layout to suit the device which will execute the kernel”. It implies that SPIR-V is data layout agnostic since you can load it with any data layout, or there are (to be specified) constraint on what a “compatible” data layout is, or you considered that it is up to the OpenCL vendor to figure out what will work or not, with the drawback that any LLVM update can break its use case.> > For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. > > Location > > From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter: > > 1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V.How important is it to “reflect it”? The SPIR-V emitter could just assert on the data layout matching what is expected.> 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V.I don’t see why you think there is an issue on the data layout in this case. Currently every target in LLVM has an expected data layout, and if the IR has been processed with a different data layout than what the target expect, it may or may not work. I believe your “thin wrapper” in llvm/lib/Target/SPIRV would declare a triple and data layout and then makes this requirement explicit. This looks like the cleaner solution to me, I’m not sure I understand why you are more in favor of option 3? Thanks, — Mehdi> 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. > > Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. > > Implementation > > About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. The current implementation uses a shared in-memory representation of SPIR-V, which facilitates supporting bi-way translation. The round-trip translated LLVM IR by the current implementation has passed OpenCL SPIR 1.2 conformance test, which proves the current implementation works. On the other hand, the SelectionDAG/MC approach would require significant tweaking compared to a conventional backend, since SPIR-V is not a low level machine ISA but a high level generic IR. Also, the SelectionDAG/MC approach only supports one-way translation from LLVM to SPIR-V. Therefore unless major concern arises, we will keep the current implementation approach. > > Maintenance > > The current implementation works by breaking down LLVM IR to instructions and re-constructing them in SPIR-V, and vice versa. Therefore the dependence of the current implementation on LLVM is mainly the C++ API in llvm/include/IR. As such, its dependence on LLVM is similar to typical module passes. Our experience with porting it among LLVM 3.2/3.4/3.6 is that the porting effort is moderate. > > Milestones > > Currently Clang can compile OpenCL 1.2/2.0 C kernel source to LLVM IR with spir/spir64 target triple, which is compatible with SPIR-V for the supported instructions, data types and builtin functions. Therefore the first milestone of the converter is to support compiling OpenCL 1.2/2.0 kernel to SPIR-V. This is also to lay the foundation for the upcoming OpenCL 2.1 C++ frontend development in Clang. The next milestone would be supporting OpenCL 2.1 C++, which hopefully would be in synch with the frontend development work. In the meantime, as the SPIR-V target becomes stable and is able to support the instructions common to OpenCL and GLSL, hopefully the GLSL frontend work and support for GLSL specific instructions would pick up and finally we would have a SPIR-V target supporting the complete SPIR-V spec. > > Testing > > We will add lit tests for SPIR-V. Also the converter would be tested by different OpenCL vendors for production quality through comprehensive conformance tests, since SPIR-V is required by OpenCL 2.1. > > Logistics > > AMD, Intel and some other SPIR WG members would join force for the development of the bi-way converter. Since supporting of SPIR-V is required by OpenCL 2.1, it is expected that OpenCL vendors would continue the maintenance efforts for supporting SPIRV target in LLVM. > > Yaxun Liu > AMD > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/f3c31b21/attachment.html>
> On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. > > Proposal of Adding SPIRV Target > > Background > > SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: > > 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. > 2. The application developer ships the application containing the SPIR-V binary to customers. > 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. > 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. > > For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. > > Location > > From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter: > > 1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. > 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V. > 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. > > Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h.If the bi-way converter logic is in llvm/lib/Target/SPIRV (libLLVMSPIRV) and there are APIs for it in llvm/include/Support/SPIRV.h (libLLVMSupport), you make Support depend on a target which is a layering violation. Can you please explain how you see this working? -Chris> A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. > > Implementation > > About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. The current implementation uses a shared in-memory representation of SPIR-V, which facilitates supporting bi-way translation. The round-trip translated LLVM IR by the current implementation has passed OpenCL SPIR 1.2 conformance test, which proves the current implementation works. On the other hand, the SelectionDAG/MC approach would require significant tweaking compared to a conventional backend, since SPIR-V is not a low level machine ISA but a high level generic IR. Also, the SelectionDAG/MC approach only supports one-way translation from LLVM to SPIR-V. Therefore unless major concern arises, we will keep the current implementation approach. > > Maintenance > > The current implementation works by breaking down LLVM IR to instructions and re-constructing them in SPIR-V, and vice versa. Therefore the dependence of the current implementation on LLVM is mainly the C++ API in llvm/include/IR. As such, its dependence on LLVM is similar to typical module passes. Our experience with porting it among LLVM 3.2/3.4/3.6 is that the porting effort is moderate. > > Milestones > > Currently Clang can compile OpenCL 1.2/2.0 C kernel source to LLVM IR with spir/spir64 target triple, which is compatible with SPIR-V for the supported instructions, data types and builtin functions. Therefore the first milestone of the converter is to support compiling OpenCL 1.2/2.0 kernel to SPIR-V. This is also to lay the foundation for the upcoming OpenCL 2.1 C++ frontend development in Clang. The next milestone would be supporting OpenCL 2.1 C++, which hopefully would be in synch with the frontend development work. In the meantime, as the SPIR-V target becomes stable and is able to support the instructions common to OpenCL and GLSL, hopefully the GLSL frontend work and support for GLSL specific instructions would pick up and finally we would have a SPIR-V target supporting the complete SPIR-V spec. > > Testing > > We will add lit tests for SPIR-V. Also the converter would be tested by different OpenCL vendors for production quality through comprehensive conformance tests, since SPIR-V is required by OpenCL 2.1. > > Logistics > > AMD, Intel and some other SPIR WG members would join force for the development of the bi-way converter. Since supporting of SPIR-V is required by OpenCL 2.1, it is expected that OpenCL vendors would continue the maintenance efforts for supporting SPIRV target in LLVM. > > Yaxun Liu > AMD > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/6a762f4f/attachment.html>
It is just a header file. All source code is under lib/Target/SPIRV since they really belong there. Those who want to use the conversion functionality just need to link with the SPIRV target library. Any suggestion about a better location for the header file? Thanks. Sam From: Chris Bieneman [mailto:beanz at apple.com] Sent: Wednesday, June 17, 2015 2:31 PM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2. The application developer ships the application containing the SPIR-V binary to customers. 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. Location>From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter:1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V. 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h. If the bi-way converter logic is in llvm/lib/Target/SPIRV (libLLVMSPIRV) and there are APIs for it in llvm/include/Support/SPIRV.h (libLLVMSupport), you make Support depend on a target which is a layering violation. Can you please explain how you see this working? -Chris A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. Implementation About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. The current implementation uses a shared in-memory representation of SPIR-V, which facilitates supporting bi-way translation. The round-trip translated LLVM IR by the current implementation has passed OpenCL SPIR 1.2 conformance test, which proves the current implementation works. On the other hand, the SelectionDAG/MC approach would require significant tweaking compared to a conventional backend, since SPIR-V is not a low level machine ISA but a high level generic IR. Also, the SelectionDAG/MC approach only supports one-way translation from LLVM to SPIR-V. Therefore unless major concern arises, we will keep the current implementation approach. Maintenance The current implementation works by breaking down LLVM IR to instructions and re-constructing them in SPIR-V, and vice versa. Therefore the dependence of the current implementation on LLVM is mainly the C++ API in llvm/include/IR. As such, its dependence on LLVM is similar to typical module passes. Our experience with porting it among LLVM 3.2/3.4/3.6 is that the porting effort is moderate. Milestones Currently Clang can compile OpenCL 1.2/2.0 C kernel source to LLVM IR with spir/spir64 target triple, which is compatible with SPIR-V for the supported instructions, data types and builtin functions. Therefore the first milestone of the converter is to support compiling OpenCL 1.2/2.0 kernel to SPIR-V. This is also to lay the foundation for the upcoming OpenCL 2.1 C++ frontend development in Clang. The next milestone would be supporting OpenCL 2.1 C++, which hopefully would be in synch with the frontend development work. In the meantime, as the SPIR-V target becomes stable and is able to support the instructions common to OpenCL and GLSL, hopefully the GLSL frontend work and support for GLSL specific instructions would pick up and finally we would have a SPIR-V target supporting the complete SPIR-V spec. Testing We will add lit tests for SPIR-V. Also the converter would be tested by different OpenCL vendors for production quality through comprehensive conformance tests, since SPIR-V is required by OpenCL 2.1. Logistics AMD, Intel and some other SPIR WG members would join force for the development of the bi-way converter. Since supporting of SPIR-V is required by OpenCL 2.1, it is expected that OpenCL vendors would continue the maintenance efforts for supporting SPIRV target in LLVM. Yaxun Liu AMD _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/054e3132/attachment.html>
On Wed, Jun 17, 2015 at 5:47 AM Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote:> Here is the revised proposal for the LLVM/SPIR-V converter. Please > comment. Thanks. > > > > Proposal of Adding SPIRV Target > > > > Background > > > > SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A > typical use case of SPIR-V is as follows: > > > > 1. An application developer uses Clang to compile an OpenCL kernel > source code to a SPIR-V binary which is common for all OpenCL platforms. > > 2. The application developer ships the application containing the > SPIR-V binary to customers. > > 3. A customer runs the application on an OpenCL platform, which > loads the SPIR-V binary through an OpenCL API function. > > 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, > changes the target triple and data layout to suit the device which will > execute the kernel, performs target specific optimizations, generates the > ISA and executes the ISA on the device. > > > > For OpenCL kernels, there is implicit data layout dependence when > compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, > a common data layout accepted by different OpenCL vendors is required. We > choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, > since it has been successfully used for supporting consumption of SPIR > 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under > discussion whether to choose the same data layout as OpenCL, or a different > data layout, or no data layout at all. > > > > Location > > > > From feedback of the previous version of the proposal, there are several > suggestions about the location for the LLVM/SPIR-V converter: > > > > 1. llvm/lib/SPIRV only, adding an option to Clang for outputting > SPIR-V. The advantage is ease of use for bi-way translation. However it > does not reflect the fact that only LLVM IR with specific target triple and > data layout can be translated to SPIR-V. > > 2. llvm/lib/SPIRV containing the main functionality of bi-way > translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a > thin wrapper as a target machine to allow Clang targeting SPIR-V. The > advantage compared with 1 is that it allows a more conventional way of > using Clang to produce SPIR-V. However it is subject to the same issue as 1 > about not reflecting the requirement on the LLVM IR which can be translated > to SPIR-V. > > 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the > requirement on the target triple and data layout for LLVM IR which can be > translated to SPIR-V. However putting the SPIR-V to LLVM converter in the > same directory is unconventional. Leaving the SPIR-V to LLVM converter out > of LLVM source tree is also not desirable since OpenCL vendors need this > functionality. > > > > Our proposal is to take approach 3 and keep the bi-way converter in > llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed > through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is > also provided to allow Clang targeting SPIR-V. The rationale is that this > directory structure better reflects the nature of SPIR-V. SPIR-V is not an > alternative representation for arbitrary LLVM IR. Instead, it is an > alternative representation for LLVM IR targeting generic OpenCL or Vulkan > platforms. It has its own specific target triple and data layout. Therefore > it makes sense for the functionality to be put under llvm/lib/Target. Also, > as an alternative representation of LLVM IR, it makes sense to have a > bi-way convertor. > > > > Implementation > > > > About the implementation of the converter, although there are suggestions > to take the SelectionDAG/MC approach, it seems not a major concern in > general. >I think you failed to understand my email then. For me, not using the common and shared legalization framework is a complete deal breaker. As you say, this is not a stable representation for *any* generic IR, only for the subset targeting a specific platform. But without a legalization layer that maps from generic IR to that specific platform's representation, we would be unable to change the canonical form that the middle end optimizers produce from IR (including the IR generated by an OpenCL frontend) without updating your legalization layer. If that legalization layer in turn is a completely separate layer from the SelectionDAG legalization layer, you've added a whole new burden on the LLVM community that doesn't seem reasonable. I think it is important that this effort shift to thinking of SPIR-V as a virtual ISA (admittedly a very special purpose one) and use common infrastructure for lowering and targeting it. At the same time, I freely acknowledge that the current infrastructure in LLVM may not be ideal for this purpose today. I think it is incumbent on your group[1] to undertake the effort of making LLVM's infrastructure better suited to your usecase rather than introducing a new set of infrastructure that is not shared with any other targets. -Chandler [1]: A footnote that is really a meta point, and not specifically about this proposal. When I say "you will have to make <whatever> significant changes to the LLVM infrastructure that you need", I'm not saying you should go away and start writing patches to this effect. Changing the core code generation infrastructure of LLVM is a really huge undertaking. If you want to do this, you'll need to first build up a reputation within the LLVM community, trust of the various developers, etc. Don't dive into the infrastructure first, you need to start with bugs, fixes, and small improvements. I realize this is a huge challenge for a lot of contributors, but changing heavily used infrastructure in really invasive ways is an extremely high-risk endeavor and I think it is reasonable that the community has a relatively high bar for contributors proposing to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/6c14bbe2/attachment.html>
Hi Mehdi, Thank you for your comments. My comments are below. Sam From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Wednesday, June 17, 2015 12:43 PM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target Hi Liu, Thanks for the detailed proposal. On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2. The application developer ships the application containing the SPIR-V binary to customers. 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. Step 4 of your “typical use case” includes "changes the target triple and data layout to suit the device which will execute the kernel”. It implies that SPIR-V is data layout agnostic since you can load it with any data layout, or there are (to be specified) constraint on what a “compatible” data layout is, or you considered that it is up to the OpenCL vendor to figure out what will work or not, with the drawback that any LLVM update can break its use case. + For OpenCL, LLVM IR translated from SPIR-V has specific data layouts, which are the data layouts for target spir/spir64. OpenCL vendor’s target data layout are assumed to be consistent with them. For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. Location From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter: 1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. How important is it to “reflect it”? The SPIR-V emitter could just assert on the data layout matching what is expected. + Putting the converter at llvm/lib/SPIRV may encourage misuse of the converter, i.e., using the converter to convert LLVM IR of arbitrary target, whereas the converter can only convert LLVM IR with spir/spir64 target. 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V. I don’t see why you think there is an issue on the data layout in this case. Currently every target in LLVM has an expected data layout, and if the IR has been processed with a different data layout than what the target expect, it may or may not work. I believe your “thin wrapper” in llvm/lib/Target/SPIRV would declare a triple and data layout and then makes this requirement explicit. This looks like the cleaner solution to me, I’m not sure I understand why you are more in favor of option 3? + Since the converter is only for converting LLVM IR of a specific target, I prefer to put it at the same location of that target. Thanks, — Mehdi 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. Implementation About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. The current implementation uses a shared in-memory representation of SPIR-V, which facilitates supporting bi-way translation. The round-trip translated LLVM IR by the current implementation has passed OpenCL SPIR 1.2 conformance test, which proves the current implementation works. On the other hand, the SelectionDAG/MC approach would require significant tweaking compared to a conventional backend, since SPIR-V is not a low level machine ISA but a high level generic IR. Also, the SelectionDAG/MC approach only supports one-way translation from LLVM to SPIR-V. Therefore unless major concern arises, we will keep the current implementation approach. Maintenance The current implementation works by breaking down LLVM IR to instructions and re-constructing them in SPIR-V, and vice versa. Therefore the dependence of the current implementation on LLVM is mainly the C++ API in llvm/include/IR. As such, its dependence on LLVM is similar to typical module passes. Our experience with porting it among LLVM 3.2/3.4/3.6 is that the porting effort is moderate. Milestones Currently Clang can compile OpenCL 1.2/2.0 C kernel source to LLVM IR with spir/spir64 target triple, which is compatible with SPIR-V for the supported instructions, data types and builtin functions. Therefore the first milestone of the converter is to support compiling OpenCL 1.2/2.0 kernel to SPIR-V. This is also to lay the foundation for the upcoming OpenCL 2.1 C++ frontend development in Clang. The next milestone would be supporting OpenCL 2.1 C++, which hopefully would be in synch with the frontend development work. In the meantime, as the SPIR-V target becomes stable and is able to support the instructions common to OpenCL and GLSL, hopefully the GLSL frontend work and support for GLSL specific instructions would pick up and finally we would have a SPIR-V target supporting the complete SPIR-V spec. Testing We will add lit tests for SPIR-V. Also the converter would be tested by different OpenCL vendors for production quality through comprehensive conformance tests, since SPIR-V is required by OpenCL 2.1. Logistics AMD, Intel and some other SPIR WG members would join force for the development of the bi-way converter. Since supporting of SPIR-V is required by OpenCL 2.1, it is expected that OpenCL vendors would continue the maintenance efforts for supporting SPIRV target in LLVM. Yaxun Liu AMD _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/e5ed2a27/attachment.html>
Hi Chandler, Thank you for your comments. We could upstream the current implementation as an experimental target, and then refactor it to use SelectionDAG/MC while already present in the LLVM tree. That way people who want to target SPIR-V now can use the experimental target, while we work on implementing the backend properly. Since the current implementation of ‘legalization’ is like a simple LLVM transformation pass, we do not expect any significant burden on the LLVM community during transition to SelectionDAG/MC. Sam From: Chandler Carruth [mailto:chandlerc at google.com] Sent: Wednesday, June 17, 2015 3:48 PM To: Liu, Yaxun (Sam); llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Wed, Jun 17, 2015 at 5:47 AM Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2. The application developer ships the application containing the SPIR-V binary to customers. 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. Location From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter: 1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. 2. llvm/lib/SPIRV containing the main functionality of bi-way translation between LLVM IR and SPIR-V, llvm/lib/Target/SPIRV containing a thin wrapper as a target machine to allow Clang targeting SPIR-V. The advantage compared with 1 is that it allows a more conventional way of using Clang to produce SPIR-V. However it is subject to the same issue as 1 about not reflecting the requirement on the LLVM IR which can be translated to SPIR-V. 3. llvm/lib/Target/SPIRV only. The advantage is that it reflects the requirement on the target triple and data layout for LLVM IR which can be translated to SPIR-V. However putting the SPIR-V to LLVM converter in the same directory is unconventional. Leaving the SPIR-V to LLVM converter out of LLVM source tree is also not desirable since OpenCL vendors need this functionality. Our proposal is to take approach 3 and keep the bi-way converter in llvm/lib/Target/SPIRV. The functionality of the bi-way converter is exposed through llvm/include/Support/SPIRV.h. A thin wrapper as a target machine is also provided to allow Clang targeting SPIR-V. The rationale is that this directory structure better reflects the nature of SPIR-V. SPIR-V is not an alternative representation for arbitrary LLVM IR. Instead, it is an alternative representation for LLVM IR targeting generic OpenCL or Vulkan platforms. It has its own specific target triple and data layout. Therefore it makes sense for the functionality to be put under llvm/lib/Target. Also, as an alternative representation of LLVM IR, it makes sense to have a bi-way convertor. Implementation About the implementation of the converter, although there are suggestions to take the SelectionDAG/MC approach, it seems not a major concern in general. I think you failed to understand my email then. For me, not using the common and shared legalization framework is a complete deal breaker. As you say, this is not a stable representation for *any* generic IR, only for the subset targeting a specific platform. But without a legalization layer that maps from generic IR to that specific platform's representation, we would be unable to change the canonical form that the middle end optimizers produce from IR (including the IR generated by an OpenCL frontend) without updating your legalization layer. If that legalization layer in turn is a completely separate layer from the SelectionDAG legalization layer, you've added a whole new burden on the LLVM community that doesn't seem reasonable. I think it is important that this effort shift to thinking of SPIR-V as a virtual ISA (admittedly a very special purpose one) and use common infrastructure for lowering and targeting it. At the same time, I freely acknowledge that the current infrastructure in LLVM may not be ideal for this purpose today. I think it is incumbent on your group[1] to undertake the effort of making LLVM's infrastructure better suited to your usecase rather than introducing a new set of infrastructure that is not shared with any other targets. -Chandler [1]: A footnote that is really a meta point, and not specifically about this proposal. When I say "you will have to make <whatever> significant changes to the LLVM infrastructure that you need", I'm not saying you should go away and start writing patches to this effect. Changing the core code generation infrastructure of LLVM is a really huge undertaking. If you want to do this, you'll need to first build up a reputation within the LLVM community, trust of the various developers, etc. Don't dive into the infrastructure first, you need to start with bugs, fixes, and small improvements. I realize this is a huge challenge for a lot of contributors, but changing heavily used infrastructure in really invasive ways is an extremely high-risk endeavor and I think it is reasonable that the community has a relatively high bar for contributors proposing to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/0c71f7e1/attachment.html>