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-VI 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 treeThese 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 informationDefining 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 targetsSPIR-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 specificallyI 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> Neil > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* 10 May 2017 15:05:22 > *To:* tstellar at redhat.com > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM > > 2017-05-03 21:04 GMT+02:00 Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org>: >> So there are really two questions here: >> 1. Should targets be required to use SelectionDAG/GlobalISEL ? > > In the past we also had a C and an LLVM-IR builder-backend (also known > as Cpp backend) which did not use instruction selection. That is, > there are other uses cases for non-SelectionDAG/GlobalISEL backends. > > I have no use for the Cpp backend, but a revival of the C backend > could be interesting. > > Michael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 21 Jun 2017, at 8:20 am, Tom Stellard <tstellar at redhat.com<mailto:tstellar at redhat.com>> wrote: 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? https://github.com/KhronosGroup/SPIRV-LLVM for a dated version (LLVM 3.6.1 and 3.8) and llvm-target-spirv<https://github.com/thewilsonator/llvm-target-spirv> and llvm<https://github.com/thewilsonator/llvm> for my up to date (w.r.t LLVM) version. 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. I think he means in the general sense, as compared to no backend at all. The only thing difficult with it is it currently stands is getting the metadata right and thats mostly lack f documentation. * 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. Yay! 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 wanta 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170621/aaa75819/attachment.html>
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. 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 > >
One of the main reasons I make a fork of KhronosGroup’s SPIRV-LLVM in the first place was due to lack of releases for downstream CI, the other motivator being the SPIRV-LLVM is still based on LLVM 3.6.1, and I would very much like to not have to continue to maintain it myself. So I would very much prefer a solution that minimises hassle for users, having the translator in addition as a wrapper for interconversions would be useful, especially for testing, but it should not be the only way. Nic> On 21 Jun 2017, at 9:18 pm, Neil Hickey <Neil.Hickey at arm.com> 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.
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 >> >> >