similar to: [LLVMdev] [RFC] Proposal for Adding SPIRV Target

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

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

From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Thursday, June 18, 2015 11:24 AM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Hi Mehdi, Thank you for your comments. My comments are below. Sam From:

On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>] > > *Sent:* Thursday, June 18, 2015 11:24 AM > *To:* Liu, Yaxun (Sam) > *Cc:* llvmdev at cs.uiuc.edu

So we have been in discussions within the Khronos SPIR-V work group on our push to get our SPIR-V code into tip LLVM and have drawn the following conclusions; * We absolutely must create a fully fledged backend that uses all the machinery that target backends are expected to use. * We probably have to split out the SPIR-V -> LLVM IR into a separate project from LLVM ala Clang et

Hey Tom, Really it was at the behest of the replies - we got a lot of feedback from the mailing list that indicated we'd be putting extra workload of people changing features of the IR if we didn't follow the same mechanisms of the other backends (mostly led by Chandler's very astute comments on the subject). Cheers, -Neil. On 07/07/15 14:43, Tom Stellard wrote: > On Tue, Jul

Khronos Group SPIR WG is working on a bi-way converter between LLVM bitcode and SPIR-V (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and is willing to upstream it to the LLVM project. The bi-way converter uses a common in-memory representation of SPIR-V. It works by breaking down a module to instructions and construct the translated module in memory then output it.

> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V

On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > Khronos Group SPIR WG is working on a bi-way converter between LLVM > bitcode and SPIR-V ( > https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and > is willing to upstream

2015-05-16 6:42 GMT+01:00 Chris Lattner <clattner at apple.com>: > > > On May 15, 2015, at 9:53 AM, Chris Bieneman <beanz at apple.com> wrote: > > > > +1 to lib/Target/SPIRV/(Reader|Writer) > > > > I really like this idea. I’ve talked with some people on both the LLVM and Khronos sides and I really think adding SPIR-V support to LLVM as an optional

'Maintenance and support obligations' - the only maintenance obligations would be don't regress our tests when you change code, that is no different from doing changes to any other target. Chandler raised some pretty important points in his reply, and we will need to address them. In Sam's original email he did say 'We are open to the SelectionDAG/MC approach if the

> On May 19, 2015, at 7:32 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote: > >> On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com <mailto:llvm at duskborn.com>> wrote: >> >> The 'backend' in

On Fri, May 15, 2015 at 11:50 AM, David Chisnall < David.Chisnall at cl.cam.ac.uk> wrote: > On 15 May 2015, at 17:53, Chris Bieneman <beanz at apple.com> wrote: > > > > +1 to lib/Target/SPIRV/(Reader|Writer) > > > > I really like this idea. I’ve talked with some people on both the LLVM > and Khronos sides and I really think adding SPIR-V support to LLVM

Hello, Since 2015 Khronos has switched to the new portable intermediate format SPIR-V, which has replaced the original SPIR. The advantage is that it offers higher portability across different toolchains. There was a talk about it at a Dev Meeting: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#17 LLVM currently only supports SPIR format for OpenCL in Clang. Several Khronos

On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was going to wait until Neil Trevett got back to me about becoming a > SPIR-V TSG advisor but this seems like just as good an opportunity. Please > see the previous discussion [1] if you have not already, there were many > relevant points made. > > First, I’d like to note

Yet another implementation of the backend, heh. I’d just started in earnest writing a tablegen based one, with the main goal of fixing the intrinsics to actually be intrinsics. I think it would be a good idea to join forces with the folk at KhronosGroup and consolidate the work done for inclusion into LLVM. Nic > On 17 Jul 2017, at 9:55 pm, Neil Henning via llvm-dev <llvm-dev at

> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: >> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I was going to wait until Neil Trevett got back to me

On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 09/12/2018 02:32 PM, Matthias Braun wrote: > > > > > >> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: > >>> On Mon,

On Tue, 11 Sep 2018 at 19:40, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: > > On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev < > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > I was going to wait until Neil Trevett got back to me

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