similar to: SPIRV-LLVM as an external tool

I agree that having the conversion live as part of LLVM is the best option going forward. libclc is an library implementation of the OpenCL builtins and I think its fine for that aspect of the converter, i.e. consumption of SPIR-V into LLVM IR in preparation for code generation by LLVM by its various backends as a library to link the generated code to, to live in an external repo. This is fine

On 02/21/2018 10:58 AM, Nicholas Wilson wrote: > I agree that having the conversion live as part of LLVM is the best option going forward. > > libclc is an library implementation of the OpenCL builtins and I think its fine for that aspect of the converter, > i.e. consumption of SPIR-V into LLVM IR in preparation for code generation by LLVM by its various backends as a library > to

On 2018-02-21 — 14:55, Tom Stellard via llvm-dev wrote: > On 02/21/2018 12:15 AM, Tomeu Vizoso via llvm-dev wrote: > > Hi, > > > > for a few months already I have been asking around for opinions on how > > people could best work together on Khronos' SPIR-V <-> LLVM-IR converter > > and some consensus seems to have formed. > > > > Most of the

> SPIR-V does not have to be a part of LLVM for you to do this. You can add > the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) > that uses the external tool to translate LLVM IR to SPIR-V. Ok. I guess if Clang community accepts this way, it would be better to set up the SPIRV converter as a tool of LLVM. So the question is are there any

> It's important to demonstrate that there is a developer community backing > the tool and that it won't be abandoned if it is added as an llvm > sub-project. > > -Tom Just to complete the picture, this is an initiative from within Khronos Group to unify our effort to make this available as an LLVM component. A number of companies have been involved in the original

> This is great to see. Is this code the basis of the forks that Anastasia talked about or did those come from somewhere else? Yes, indeed the base is https://github.com/KhronosGroup/SPIRV-LLVM/ and then there are multiple forks that include some rework as well (some of which were announced on the LLVM channels). I think the biggest problems we are trying to solve is: 1. Keeping up to date

On Feb 27, 2018, at 10:25 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 02/27/2018 05:07 AM, Anastasia Stulova wrote: >>> SPIR-V does not have to be a part of LLVM for you to do this. You can add >>> the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) >>> that uses the external tool to translate

On 02/21/2018 12:15 AM, Tomeu Vizoso via llvm-dev wrote: > Hi, > > for a few months already I have been asking around for opinions on how > people could best work together on Khronos' SPIR-V <-> LLVM-IR converter > and some consensus seems to have formed. > > Most of the people I talked to favored having the converter become an > external tool within the LLVM

On 02/21/2018 03:34 PM, Pierre Moreau wrote: > On 2018-02-21 — 14:55, Tom Stellard via llvm-dev wrote: >> On 02/21/2018 12:15 AM, Tomeu Vizoso via llvm-dev wrote: >>> Hi, >>> >>> for a few months already I have been asking around for opinions on how >>> people could best work together on Khronos' SPIR-V <-> LLVM-IR converter >>> and

On 02/26/2018 09:25 AM, Anastasia Stulova wrote: > >> This is great to see. Is this code the basis of the forks that Anastasia > talked about or did those come from somewhere else? > > > Yes, indeed the base is https://github.com/KhronosGroup/SPIRV-LLVM/ and then there are multiple forks that include some rework as well (some of which were announced on the LLVM channels).

On 02/27/2018 05:07 AM, Anastasia Stulova wrote: >> SPIR-V does not have to be a part of LLVM for you to do this. You can add >> the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) >> that uses the external tool to translate LLVM IR to SPIR-V. > > > Ok. I guess if Clang community accepts this way, it would be better to set up

Hi Chris, The main benefit for LLVM to include SPIRV support directly is to increase the number of users and developers in the area of heterogeneous computing, e.g. GPUs, FPGAs, DSPs. We want to increase the number of such devices that LLVM natively supports by adding compilation to SPIRV due to the shortage of proprietary backends in upstream LLVM. Just to clarify we are currently suggesting

Thanks for your feedback Philip. Could you perhaps explain what the downsides to LLVM are of accepting this as a subproject as I can't really see any myself. Neil ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> Sent: 06 March 2018 23:07:54 To: Anastasia Stulova; Chris

On 27 Feb 2018, at 9:07 pm, Anastasia Stulova via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > SPIR-V does not have to be a part of LLVM for you to do this. You can add > the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) > that uses the external tool to translate LLVM IR to SPIR-V. Ok. I guess

On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: > >> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: > > Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we

I note that there was a talk recently at EuroLLVM SPIR-V and LLVM about and so I want to get this message out soon so as to avoid duplicated effort. I have an up to date backend for SPIR-V on an up to date fork (~2-3 weeks behind) of LLVM, transplanted and “modernised” from Khronos’ SPIRV-LLVM that I plan on integrating into LLVM trunk. While it is usable in it’s current form there are several

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.

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

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

> On 27 Sep 2017, at 8:21 pm, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote: > > Hi there, > > any news on coordination? We have customers who are successfully using > Mesa in their products, and that are now asking about OpenCL. None yet, I’m still waiting for IWOCL to spearhead the coordination. > My current impression is that easiest would be to do what Tom