similar to: SPIR-V & LLVM JIT Compiler

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

On 09/27/2017 05:21 AM, Tomeu Vizoso wrote: > 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

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 31 Jul 2017, at 3:23 pm, Neil Henning <llvm at duskborn.com> wrote: > > Yup to a third backend sorry ;) > > We want a backend in tip LLVM - but I think approaching this from OpenCL SPIR-V's perspective (whereby almost everything in LLVM is 1:1 implementable in OpenCL SPIR-V) will cause a headache when adding Vulkan SPIR-V's more strict requirements. I’m not

> 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

On 06/21/2017 09:18 AM, Neil Hickey wrote: > Hi Tom, > > I don't disagree, on a technical level, with any of your points. This is, as you have already pointed out, not the first time we have had this discussion and so far, two years after these discussions were first opened we are not any nearer to a solution that makes sense for all stake holders, hence why I think it prudent to

> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case

> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’. The *entire point* of my email was that that is only one of two use cases of SPIR-V. As I said above, it’s a serialization format between a frontend and a

> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com> wrote: > > From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than

'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 1 May 2017, at 11:53 pm, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > First of all you may want to review the thread from a few years ago about putting a SPIR-V target into LLVM: > http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html Thanks I will take a look. > The fact that the SPIR-V

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

+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 program serialization format would be fantastic. I think it would make it even easier for LLVM-based tools to be integrated into GPU authoring and execution pipelines. I’m really excited to see this moving

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

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:

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.

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

On Fri, May 22, 2015 at 9:29 AM, Philip Reames <listmail at philipreames.com> wrote: > Let me start by emphasizing that I only speak for myself. This is my > opinion, and nothing more. > > On 05/22/2015 03:55 AM, Neil Henning wrote: >> >> 'Maintenance and support obligations' - the only maintenance obligations >> would be don't regress our tests