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 lists.llvm.org> wrote: > > Hey all, > > Code finally got through legal, but the repo is live here https://github.com/google/clspv > > This codebase is somewhere between alpha/beta as an estimate, but we've pushed a 1 million line OpenCL C codebase through it and got fully formed Vulkan SPIR-V out the other end. > > I did not want to make the mistake of forking LLVM/Clang - so there are a bunch of passes in there that are us undoing things that Clang has options for (if we had a SPIRV triple). > > Most of the meat of the producer is in https://github.com/google/clspv/blob/master/lib/SPIRVProducerPass.cpp > > Hope this helps aid any decisions by the list. > > Cheers, > -Codeplay Neil. > > On 2017-06-22 03:08, Tom Stellard via llvm-dev wrote: >> 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 explore other approaches, approaches that may not be the most efficient engineering solution, but approaches that allow us to make some kind of forward progress. >>> My motivation in this is having a solution that is well integrated with tooling that the ecosystem already uses and is comfortable with. Certainly coming from OpenCL C and C++, clang is an often used tool for compiling, and this already lives within the llvm project, allowing an option in clang that anyone can add to their compile line, which seamlessly generates SPIR-V for further consumption by an OpenCL or Vulkan runtime is, in my mind, the lowest barrier for adoption, and as such, likely to be the one that gets the most traction. >>> The barrier to getting the translator integrated into LLVM revolves around the ties that it creates between the future evolution of LLVM-IR and SPIR-V, two specifications that are controlled by different communities, whereas recasting the translator as a backend removes that tie, or at least forces the LLVM-IR to go through a lowering/ legalisation step, and also, if it breaks can be more easily disabled. >>> Assuming the objective is to keep this in llvm for ease of use by end users, and we do not want to pursue the full backend approach, there are a number of other options we could explore. >>> 1) Allow something like a backend to exist in LLVM, which can be switched off if it breaks, that allows for these types of translations between different intermediate languages, but doesn't have the requirement of going through MachineInstructions, i.e. it isn't really a backend. This mechanism could also have been used to target WebAssembly for example, and any other IR/ILs that we would like LLVM-IR to have a route to going forward. >>> 2) Create a tool, in llvm/tools similar to clang that creates a library and separate tool to provide the same functionality as the LLVM<->SPIR-V translator discussed previously. This could be officially hosted, like clang, if the community felt that appropriate, and would allow easy integration of the different tools, or being called as a library, to generate SPIR-V from LLVM. >> I think these are both possible solutions, but we aren't going to be able >> to know which is best until there is some code to look at and review. >> This is why I suggest moving whatever existing code there is into its own >> public repository while it is cleaned up and improved. I'm not suggesting >> this as a long term solution, but just for a few months or however long it >> takes to get clean code that builds against trunk, so that people can start >> looking at and reviewing. >> -Tom >>> P.S. >>> The OpenCL over Vulkan work I mentioned is not yet open sourced but I believe the intention is to do so "soon". >>>> -----Original Message----- >>>> From: Tom Stellard [mailto:tstellar at redhat.com] >>>> Sent: 21 June 2017 01:21 >>>> To: Neil Hickey; llvm-dev at lists.llvm.org >>>> Cc: Nicholas Wilson; nd >>>> Subject: Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM >>>> On 06/20/2017 05:41 PM, Neil Hickey wrote: >>>>> Hi all, I'd like to kick this discussion off again, and summarise the points that >>>> have been expressed so far. >>>>> Firstly, as a member of Khronos, I'd like to state that this would be a very >>>> interesting development. >>>> Hi Neil, >>>> I am very interested in having a good LLVM IR -> SPIR-V solution, and I think >>>> it's great that Khronos is interested in putting effort into making this happen, >>>> however, I disagree with the approach you have outlined mostly because I >>>> don't think it is the most effective use of developer resources. >>>>> Khronos, for those who don't know, is a standards body developing open >>>> standards for accelerating rich media content on a wide variety of platforms, >>>> including GPUs as an example. >>>>> Khronos is made up of a large number of companies across a range of >>>> industries, but as an example, ARM, Google, Intel, Imagination are all >>>> members. >>>>> Khronos members are already working on writing backend for llvm that >>>> retarget SPIR-V, for example, taking LLVM-IR compiled from OpenCL and >>>> targeting this at something that can accept Vulkan, so there is clear interest >>>> within the community to see this happen. >>>> Is this code available anywhere? >>>>> Firstly, there are a number of benefits to having SPIR-V in LLVM as a >>>> backend, both to SPIR-V, the ecosystem and to LLVM. >>>>> * Allows any frontend targeting llvm to also target SPIR-V >>>> I think people over estimate the difficulty of integrating a direct LLVM IR to >>>> SPIR-V translator with frontends that emit LLVM IR. All a direct translator >>>> does is take LLVM IR as an input and produce SPIR-V as an output, interacting >>>> with it is not that complicated. I think whatever challenges this presents >>>> would be much easier to solve than implementing a full GlobalIsel based >>>> backend. >>>>> * Improves robustness of open source tooling for SPIR-V >>>>> * Single place for toolchain - People don't need to knit repositories >>>>> together from multiple locations >>>>> * Compatibility between LLVM and SPIR-V - As SPIR-V is integrated it >>>>> will always track top of tree >>>> These are advantages of having an LLVM IR to SPIR-V translator in tree, but >>>> you get these same advantages no matter what type of translator it is (e.g. >>>> direct LLVM IR to SPIR-V or GlobalISel SPIR-V backend). >>>>> * We can create a target triple to subset what dialect of SPIR-V we >>>>> are targeting >>>>> * Using the aforementioned triple we can guide optimisations that >>>>> take target information >>>> Defining a triple does not require a backend. >>>>> * Challenges of implementing SPIR-V backend can influence LLVM >>>>> backend development, to improve LLVM usability by less conventional >>>>> targets >>>> SPIR-V isn't just unconventional, it's also a higher-level language than all the >>>> other targets, which are all closer to assembly languages. >>>>> * Benefits LLVM by improving support for GPU code generation >>>>> specifically >>>> I agree with this. >>>>> I'd also like to touch specifically on a point that I believe was originally made >>>> by Tom. >>>>> If the initial implementation of the SPIR-V backend went straight for >>>> GlobalISel and only GlobalISel then we would remove the need to worry >>>> about SelectionDAG and would remove some of the complexity from the >>>> translation step. >>>> While I think GlobalISel would be better than SelectionDAG it still is not a >>>> good fit for a language like SPIR-V. The main problem with both GlobalISel >>>> and SelectionDAG is that you are taking a high-level IR (LLVM IR), translating >>>> it to an low level, assembly-like IR (MachineInstr) and then translating it back >>>> to a high-level IR (SPIR-V). From a technical perspective, this is a much >>>> inferior solution than generating SPIR-V from LLVM IR directly, because you >>>> will be losing information in the translation that will be very difficult, if not >>>> impossible, to recover. It's also much more work than a direct translation to >>>> SPIR-V, so you will be investing extra engineering effort in order to generate >>>> worse SPIR-V. >>>>> So as a proposal, could I suggest the following next steps? >>>>> 1) Add a dummy SPIR-V target machine to llvm, replete with target >>>>> triple >>>>> 2) Implement an experimental backend making use of globalisel to >>>>> target SPIR-V code generation >>>>> 3) Add tests to verify correct execution >>>>> Moving forward, the plan would be to develop this into a fully featured and >>>> complete backend, with a complete set of tests, but targeting GlobalISel >>>> exclusively. >>>> As I said before, I disagree with this approach. I don't think doing a GlobalIsel >>>> based SPIR-V backend is a good use of engineering resources nor will it >>>> produce the best quality of code. >>>> I think you should re-evaluate your goals and decide, which of your goals can >>>> be met by having an in-tree solution (no matter what that solution is direct >>>> translator, GlobalISel backend or something else), and which of your goals >>>> are met by having a GlobalISel-based backend. I think it's important to >>>> separate those two ideas, because my observation is that the reason people >>>> favor doing a GlobalISel or SelectionDAG based backend is because it is the >>>> easiest way to get something in tree, and not because it is the best technical >>>> solution, which is a not a good reason to make this kind of decision. >>>> From past discussions, one of the main reasons some LLVM developers did >>>> not want a direct LLVM IR to SPIR-V translator in tree is that it would >>>> essentially be introducing a second legalization framework (or third now that >>>> we have GlobalIsel), which would place an increased maintenance burden on >>>> the community. >>>> There wasn't a unanimous objection from the community, however, and I >>>> think there is enough interest in this project that we could come up with >>>> some kind of solution for an in-tree direct LLVM IR translator. However, it's >>>> really hard to argue for a big change like this without any code or existing >>>> user base to show the community how the benefits of this outweigh the >>>> costs. >>>> I think a direct LLVM IR to SPIR-V translator is the best technical solution, this >>>> is why my recommendation is to start by taking the existing code that >>>> implements a direct LLVM IR to SPIR-V translator and develop it as its own >>>> out-of-tree project, and by out-of-tree I mean a complete separate project >>>> from LLVM not just a fork of it. Having an out-of-tree project will allow you >>>> to improve the code and build up a community, without getting bogged >>>> down by lengthy mailing list discussions or trying to integrate major changes >>>> to core LLVM infrastructure in order to accommodate your translator. >>>> Once you have a good solution with a strong userbase, I think you will be in a >>>> much better position to work with the community to come up with a solution >>>> to integrate your translator into the official tree. >>>> -Tom >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hey Nicolas, Yup - one thing to note is that for the clspv project the only target we care about is Vulkan SPIR-V. It's quite a bit more difficult to target Vulkan SPIR-V because there are a ton of extra restrictions on top of what OpenCL SPIR-V has. For us, doing a clean-room implementation on tip of tree with no patches to Clang/LLVM was a requirement. Cheers, -Codeplay Neil. On 2017-07-18 04:18, Nicholas Wilson via llvm-dev wrote:> 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 lists.llvm.org> wrote: >> >> Hey all, >> >> Code finally got through legal, but the repo is live here >> https://github.com/google/clspv >> >> This codebase is somewhere between alpha/beta as an estimate, but >> we've pushed a 1 million line OpenCL C codebase through it and got >> fully formed Vulkan SPIR-V out the other end. >> >> I did not want to make the mistake of forking LLVM/Clang - so there >> are a bunch of passes in there that are us undoing things that Clang >> has options for (if we had a SPIRV triple). >> >> Most of the meat of the producer is in >> https://github.com/google/clspv/blob/master/lib/SPIRVProducerPass.cpp >> >> Hope this helps aid any decisions by the list. >> >> Cheers, >> -Codeplay Neil. >> >> On 2017-06-22 03:08, Tom Stellard via llvm-dev wrote: >>> 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 explore >>>> other approaches, approaches that may not be the most efficient >>>> engineering solution, but approaches that allow us to make some kind >>>> of forward progress. >>>> My motivation in this is having a solution that is well integrated >>>> with tooling that the ecosystem already uses and is comfortable >>>> with. Certainly coming from OpenCL C and C++, clang is an often used >>>> tool for compiling, and this already lives within the llvm project, >>>> allowing an option in clang that anyone can add to their compile >>>> line, which seamlessly generates SPIR-V for further consumption by >>>> an OpenCL or Vulkan runtime is, in my mind, the lowest barrier for >>>> adoption, and as such, likely to be the one that gets the most >>>> traction. >>>> The barrier to getting the translator integrated into LLVM revolves >>>> around the ties that it creates between the future evolution of >>>> LLVM-IR and SPIR-V, two specifications that are controlled by >>>> different communities, whereas recasting the translator as a backend >>>> removes that tie, or at least forces the LLVM-IR to go through a >>>> lowering/ legalisation step, and also, if it breaks can be more >>>> easily disabled. >>>> Assuming the objective is to keep this in llvm for ease of use by >>>> end users, and we do not want to pursue the full backend approach, >>>> there are a number of other options we could explore. >>>> 1) Allow something like a backend to exist in LLVM, which can be >>>> switched off if it breaks, that allows for these types of >>>> translations between different intermediate languages, but doesn't >>>> have the requirement of going through MachineInstructions, i.e. it >>>> isn't really a backend. This mechanism could also have been used to >>>> target WebAssembly for example, and any other IR/ILs that we would >>>> like LLVM-IR to have a route to going forward. >>>> 2) Create a tool, in llvm/tools similar to clang that creates a >>>> library and separate tool to provide the same functionality as the >>>> LLVM<->SPIR-V translator discussed previously. This could be >>>> officially hosted, like clang, if the community felt that >>>> appropriate, and would allow easy integration of the different >>>> tools, or being called as a library, to generate SPIR-V from LLVM. >>> I think these are both possible solutions, but we aren't going to be >>> able >>> to know which is best until there is some code to look at and review. >>> This is why I suggest moving whatever existing code there is into its >>> own >>> public repository while it is cleaned up and improved. I'm not >>> suggesting >>> this as a long term solution, but just for a few months or however >>> long it >>> takes to get clean code that builds against trunk, so that people can >>> start >>> looking at and reviewing. >>> -Tom >>>> P.S. >>>> The OpenCL over Vulkan work I mentioned is not yet open sourced but >>>> I believe the intention is to do so "soon". >>>>> -----Original Message----- >>>>> From: Tom Stellard [mailto:tstellar at redhat.com] >>>>> Sent: 21 June 2017 01:21 >>>>> To: Neil Hickey; llvm-dev at lists.llvm.org >>>>> Cc: Nicholas Wilson; nd >>>>> Subject: Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM >>>>> On 06/20/2017 05:41 PM, Neil Hickey wrote: >>>>>> Hi all, I'd like to kick this discussion off again, and summarise >>>>>> the points that >>>>> have been expressed so far. >>>>>> Firstly, as a member of Khronos, I'd like to state that this would >>>>>> be a very >>>>> interesting development. >>>>> Hi Neil, >>>>> I am very interested in having a good LLVM IR -> SPIR-V solution, >>>>> and I think >>>>> it's great that Khronos is interested in putting effort into making >>>>> this happen, >>>>> however, I disagree with the approach you have outlined mostly >>>>> because I >>>>> don't think it is the most effective use of developer resources. >>>>>> Khronos, for those who don't know, is a standards body developing >>>>>> open >>>>> standards for accelerating rich media content on a wide variety of >>>>> platforms, >>>>> including GPUs as an example. >>>>>> Khronos is made up of a large number of companies across a range >>>>>> of >>>>> industries, but as an example, ARM, Google, Intel, Imagination are >>>>> all >>>>> members. >>>>>> Khronos members are already working on writing backend for llvm >>>>>> that >>>>> retarget SPIR-V, for example, taking LLVM-IR compiled from OpenCL >>>>> and >>>>> targeting this at something that can accept Vulkan, so there is >>>>> clear interest >>>>> within the community to see this happen. >>>>> Is this code available anywhere? >>>>>> Firstly, there are a number of benefits to having SPIR-V in LLVM >>>>>> as a >>>>> backend, both to SPIR-V, the ecosystem and to LLVM. >>>>>> * Allows any frontend targeting llvm to also target SPIR-V >>>>> I think people over estimate the difficulty of integrating a direct >>>>> LLVM IR to >>>>> SPIR-V translator with frontends that emit LLVM IR. All a direct >>>>> translator >>>>> does is take LLVM IR as an input and produce SPIR-V as an output, >>>>> interacting >>>>> with it is not that complicated. I think whatever challenges this >>>>> presents >>>>> would be much easier to solve than implementing a full GlobalIsel >>>>> based >>>>> backend. >>>>>> * Improves robustness of open source tooling for SPIR-V >>>>>> * Single place for toolchain - People don't need to knit >>>>>> repositories >>>>>> together from multiple locations >>>>>> * Compatibility between LLVM and SPIR-V - As SPIR-V is integrated >>>>>> it >>>>>> will always track top of tree >>>>> These are advantages of having an LLVM IR to SPIR-V translator in >>>>> tree, but >>>>> you get these same advantages no matter what type of translator it >>>>> is (e.g. >>>>> direct LLVM IR to SPIR-V or GlobalISel SPIR-V backend). >>>>>> * We can create a target triple to subset what dialect of SPIR-V >>>>>> we >>>>>> are targeting >>>>>> * Using the aforementioned triple we can guide optimisations that >>>>>> take target information >>>>> Defining a triple does not require a backend. >>>>>> * Challenges of implementing SPIR-V backend can influence LLVM >>>>>> backend development, to improve LLVM usability by less >>>>>> conventional >>>>>> targets >>>>> SPIR-V isn't just unconventional, it's also a higher-level language >>>>> than all the >>>>> other targets, which are all closer to assembly languages. >>>>>> * Benefits LLVM by improving support for GPU code generation >>>>>> specifically >>>>> I agree with this. >>>>>> I'd also like to touch specifically on a point that I believe was >>>>>> originally made >>>>> by Tom. >>>>>> If the initial implementation of the SPIR-V backend went straight >>>>>> for >>>>> GlobalISel and only GlobalISel then we would remove the need to >>>>> worry >>>>> about SelectionDAG and would remove some of the complexity from the >>>>> translation step. >>>>> While I think GlobalISel would be better than SelectionDAG it still >>>>> is not a >>>>> good fit for a language like SPIR-V. The main problem with both >>>>> GlobalISel >>>>> and SelectionDAG is that you are taking a high-level IR (LLVM IR), >>>>> translating >>>>> it to an low level, assembly-like IR (MachineInstr) and then >>>>> translating it back >>>>> to a high-level IR (SPIR-V). From a technical perspective, this is >>>>> a much >>>>> inferior solution than generating SPIR-V from LLVM IR directly, >>>>> because you >>>>> will be losing information in the translation that will be very >>>>> difficult, if not >>>>> impossible, to recover. It's also much more work than a direct >>>>> translation to >>>>> SPIR-V, so you will be investing extra engineering effort in order >>>>> to generate >>>>> worse SPIR-V. >>>>>> So as a proposal, could I suggest the following next steps? >>>>>> 1) Add a dummy SPIR-V target machine to llvm, replete with target >>>>>> triple >>>>>> 2) Implement an experimental backend making use of globalisel to >>>>>> target SPIR-V code generation >>>>>> 3) Add tests to verify correct execution >>>>>> Moving forward, the plan would be to develop this into a fully >>>>>> featured and >>>>> complete backend, with a complete set of tests, but targeting >>>>> GlobalISel >>>>> exclusively. >>>>> As I said before, I disagree with this approach. I don't think >>>>> doing a GlobalIsel >>>>> based SPIR-V backend is a good use of engineering resources nor >>>>> will it >>>>> produce the best quality of code. >>>>> I think you should re-evaluate your goals and decide, which of your >>>>> goals can >>>>> be met by having an in-tree solution (no matter what that solution >>>>> is direct >>>>> translator, GlobalISel backend or something else), and which of >>>>> your goals >>>>> are met by having a GlobalISel-based backend. I think it's >>>>> important to >>>>> separate those two ideas, because my observation is that the reason >>>>> people >>>>> favor doing a GlobalISel or SelectionDAG based backend is because >>>>> it is the >>>>> easiest way to get something in tree, and not because it is the >>>>> best technical >>>>> solution, which is a not a good reason to make this kind of >>>>> decision. >>>>> From past discussions, one of the main reasons some LLVM developers >>>>> did >>>>> not want a direct LLVM IR to SPIR-V translator in tree is that it >>>>> would >>>>> essentially be introducing a second legalization framework (or >>>>> third now that >>>>> we have GlobalIsel), which would place an increased maintenance >>>>> burden on >>>>> the community. >>>>> There wasn't a unanimous objection from the community, however, and >>>>> I >>>>> think there is enough interest in this project that we could come >>>>> up with >>>>> some kind of solution for an in-tree direct LLVM IR translator. >>>>> However, it's >>>>> really hard to argue for a big change like this without any code or >>>>> existing >>>>> user base to show the community how the benefits of this outweigh >>>>> the >>>>> costs. >>>>> I think a direct LLVM IR to SPIR-V translator is the best technical >>>>> solution, this >>>>> is why my recommendation is to start by taking the existing code >>>>> that >>>>> implements a direct LLVM IR to SPIR-V translator and develop it as >>>>> its own >>>>> out-of-tree project, and by out-of-tree I mean a complete separate >>>>> project >>>>> from LLVM not just a fork of it. Having an out-of-tree project >>>>> will allow you >>>>> to improve the code and build up a community, without getting >>>>> bogged >>>>> down by lengthy mailing list discussions or trying to integrate >>>>> major changes >>>>> to core LLVM infrastructure in order to accommodate your >>>>> translator. >>>>> Once you have a good solution with a strong userbase, I think you >>>>> will be in a >>>>> much better position to work with the community to come up with a >>>>> solution >>>>> to integrate your translator into the official tree. >>>>> -Tom >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 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 approaching this from OpenCL’s perspective so much as approaching it from LLVM’s perspective. i.e. I want a solution that * removes the dependance on Itanium mangled C++ (windows support. Also I don't care for C++, I am developing for a different front end) * will be acceptable by the LLVM folks (so I don't have to maintain it by myself). to that end I’m using tablegen and intrinsics, although I’m busy with other things at the moment (if you think you would get use from them, please feel free to use the `.td`s). But I feel that approach is not at odds with getting something that works well for Vulkan, consider that the other backends are also not much more than a bunch of IR passes. Other than restrictions on pointers and associated aliasing, and some additional loop requirements (OpLoopMerge and reducibility) what other restrictions does Vulkan have? I’ve only done a cursory glance over the non instruction parts of the spec.> The vulkan GLSL extended instructions are here - https://www.khronos.org/registry/spir-v/specs/1.0/GLSL.std.450.htmlThanks, they look much less convoluted than OpenCL’s.> An example of where we'd need significant changes to support Vulkan https://github.com/google/clspv/blob/master/lib/ReplacePointerBitcastPass.cpp (Vulkan SPIR-V does not allow pointer bitcasts at all - we needed to transform any code that used this pattern into a load as the original type and then bitcast the value instead). I am not a backend person - it'd be useful to me if anyone who is a backend person could tell me if the type legalization could handle this in a 'real' backend?Sorry I’m not a backend person either. 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 don't get around to anything I’m sure we can organise something at IWOCL. Nic (Sorry forgot to hit reply all last time)
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 don't get around to anything I’m sure we can organise something at IWOCL.Hi there, any news on coordination? We have customers who are successfully using Mesa in their products, and that are now asking about OpenCL. My current impression is that easiest would be to do what Tom suggested before, and only re-evaluate inclusion in LLVM proper once things are more mature. One path for me would be to take Khronos' or Nic's work and convert it into something that can be packaged by Linux distributions (so it needs to work with the latest LLVM release, with no patches). Another path would be to extend clspv to cover the whole of OpenCL, but I don't know if Codeplay/Google are interested in taking such patches. Is here interest in coordinating efforts? Regards, Tomeu