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. Currently it supports SPIR-V common instructions and OpenCL specific instructions. Supporting of other languages is under consideration. We plan to refactor the LLVM to SPIR-V converter as a backend at llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in an unconventional backend which does not use SelectionDAG/MC, we would like to know whether it is acceptable. We are open to the SelectionDAG/MC approach if the community recommends it. For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project. Any comments are welcome. Thanks. Yaxun Liu AMD
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 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. Currently it supports SPIR-V common instructions and OpenCL specific instructions. Supporting of other languages is under consideration. > > We plan to refactor the LLVM to SPIR-V converter as a backend at llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in an unconventional backend which does not use SelectionDAG/MC, we would like to know whether it is acceptable. We are open to the SelectionDAG/MC approach if the community recommends it.I believe that the ‘how to write a backend’ documentation recommends against using SelectionDAG for generating code for other virtual instruction sets. I don’t think that there’s any benefit to forcing a back end to use the generic infrastructure, unless it makes sense for that back end to do so.> For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project.To me, this is no different from any other front end, so should probably live in a separate repository (though ideally an LLVM-hosted one that is integrated with buildbots and kept up to date). David
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 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. Currently it supports SPIR-V > common instructions and OpenCL specific instructions. Supporting of other > languages is under consideration. > > > > We plan to refactor the LLVM to SPIR-V converter as a backend at > llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will > result in an unconventional backend which does not use SelectionDAG/MC, we > would like to know whether it is acceptable. We are open to the > SelectionDAG/MC approach if the community recommends it. > > I believe that the ‘how to write a backend’ documentation recommends > against using SelectionDAG for generating code for other virtual > instruction sets. I don’t think that there’s any benefit to forcing a back > end to use the generic infrastructure, unless it makes sense for that back > end to do so. > > > For the SPIR-V to LLVM converter, we are seeking suggestions on its > proper location in the LLVM project. > > To me, this is no different from any other front end, so should probably > live in a separate repository (though ideally an LLVM-hosted one that is > integrated with buildbots and kept up to date). >Honestly, SPIR-V seems a little bit more like a quirky program serialization format. It's not a source language or an ISA. It might be better to treat it like the bitcode reader/writer and have both in one place. Something like lib/Target/SPIRV/(Writer|Reader)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150513/b1ec7f7f/attachment.html>
Sorry for coming late to the thread, I was traveling and then quite sick, and am trying to catch up on things. I'm generally in favor of having a SPIR-V target in upstream LLVM. There have been lots of folks on the thread that have indicated the many reasons this is advantageous. I agree with them. However, I have a few of concerns about exactly how this is implemented that I want to bring up. 1) I don't think this should live along side lib/Bitcode. For better or worse, doing that would make it *the* LLVM stable program serialization framework, and I'm at least *very* uncomfortable with that at this stage. SPIR-V was developed by a party outside of the LLVM community, and I don't really know why we should consider it to be a viable canonical stable serialization format. I think it makes much more sense for it to be clearly *optional* (the way a "Target" in LLVM is today) and predicated on an external spec (the way a "Target" in LLVM is today). From this perspective, all of the "Target" machinery in LLVM is actually exactly right -- it can be optional, it can be omitted, and wired up to a triple, etc. 2) I think we need to be really careful about exactly what the mechanism is that it uses to serialize. I realize that the SelectionDAG is a pretty terrible fit for what SPIR-V wants to do, but skipping it has a significant problem. Currently, we have a legalization framework in the SelectionDAG. If I add a new type or a new operation to LLVM and I can generically type legalize or expand it into other operations, I don't have to update every single target (some of which I may not know anything about) to support that construct. I think it is critical to preserve this contract even with SPIR-V. Currently, this could be done easily just by abusing in a minor way the legalization facilities of SelectionDAG. I'd love it if we had a more isolated legalization framework we could use instead, but I'd like to not grow *two* legalization frameworks that the LLVM community (that is, not the SPIR-V maintainers) have to update when making general IR changes. I'm not sure what the best approach is here, but I think it's really critical to clearly and directly address this problem. To give you an idea of what I'm worried about in #2, imagine that we both extend the IR to support some new construct, *and* we make that new construct *canonical*. This would cause the existing IR produced by frontends to optimize into something that the SPIR-V "target" wasn't prepared for and would have to be taught about to continue passing its basic tests. I would like for teaching the SPIR-V "target" to not be a completely separate overhead from teaching the actual machine targets about this, which we usually do today by providing an obvious legalization strategy for the new construct to the SelectionDAG and falling back to that on most targets. I'm somewhat worried about this due to changes to the IR *operations*, but I'm actually more worried about changes to the IR *types* or even *type systems*. If the SPIR-V stuff doesn't do type legalization of some form, and we want to change the fundamental way LLVM deals with (for example) FCAs (whether to get rid of them, or handle them in a "better" way, or whatever), then I'm worried adding SPIR-V will add more road blocks to something that is already really hard. That doesn't seem like the right design to me. All that said, I think it is totally fine to put the "frontend" which reads in SPIR-V and produces IR ... really wherever you want. It could live inside the "Target" as some have suggested or somewhere else. Having it live inside the "Target" would have some advantages of making it easy to exclude from a build if folks aren't using it (for whatever reason). -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150521/e247e681/attachment.html>
After following the thread through the rounds of discussion that have happened, I have serious concern about this proposal and believe that it should not land as proposed. I am not opposed to the idea of SPIR, but the current proposal is lacking key details and could be construed to imply maintenance and support obligations on the community as a whole which are not clearly defined, much less widely discussed and agreed to. I would suggest that interested parties need to settle on a usage model, what the model implies for the rest of LLVM, and come back with a more detailed specific proposal. From what I've gathered so far, it really sounds like there are two proposals within one here. The first is a SPIR-frontend targeting arbitrary backends. The usage model sounds like an existing SPIR program being compiled to either x86 (say for testing purposes) or one of the existing GPU focused backends. To me, this sounds like the less invasive part since none of the concerns about data layout (or lack there of) apply. By the time we're compiling a SPIR program to a particular target, we should be able to optimize using target specific information. My suggestion would be to establish a new repository (hosted on llvm.org) which holds this frontend. I have seen no reason this should live in the main llvm or clang repositories in the discussion to date. The second sounds like it's a proposal to have Clang support an SPIR backend. Exactly what form this would take appears to be really unclear and the implications for the project have not be spelled out. In particular, it's not clear to me that preserving all the invariants needed to emit SPIR through the optimizer is even possible with our current IR and type system. I would be actively opposed to seeing changes in this direction land without substaintial further discussion and active contribution/ownership by an existing active member of the LLVM community. Philip On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) 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 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. Currently it supports SPIR-V common instructions and OpenCL specific instructions. Supporting of other languages is under consideration. > > We plan to refactor the LLVM to SPIR-V converter as a backend at llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in an unconventional backend which does not use SelectionDAG/MC, we would like to know whether it is acceptable. We are open to the SelectionDAG/MC approach if the community recommends it. > > For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project. > > Any comments are welcome. Thanks. > > Yaxun Liu > AMD > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
'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 community recommends it.' <- I would infer from Chandler's email that he is most definitely recommending this, and if the community as a whole believes this is the direction we should take then we are happy to proceed in that way. Really though our 'proposal' is that we have code that does bi-way conversion from LLVM IR <-> SPIR-V, we are asking the community where we can place it in the tree that makes most sense. We believe that there will be real benefit for people to write their own shader/kernel languages using the awesome infrastructure that LLVM and Clang provides, and I for one want to enable the community to do just that.> I would be actively opposed to seeing changes in this direction land > without substaintial further discussion and active > contribution/ownership by an existing active member of the LLVM > community.We would be very happy for 'an existing active member of the LLVM community' to help us in our endeavours, but to 'actively oppose' the inclusion of our code based (aside from Chandler's concerns that I have already addressed) on a minor niggle with the data layout (which as Sam pointed out is as easy as using the data layout that exists at present for the SPIR/SPIR64 targets) seems rather harsh. The main issue of contention has been around 'is it a target'. I still think the most unobtrusive way for us to proceed here is to add it as a target that is only enabled via the experimental targets mechanism (like many new targets have been before) and then we can evolve the code from there. -Neil. On 22/05/15 06:34, Philip Reames wrote:> After following the thread through the rounds of discussion that have > happened, I have serious concern about this proposal and believe that > it should not land as proposed. I am not opposed to the idea of SPIR, > but the current proposal is lacking key details and could be construed > to imply maintenance and support obligations on the community as a > whole which are not clearly defined, much less widely discussed and > agreed to. > > I would suggest that interested parties need to settle on a usage > model, what the model implies for the rest of LLVM, and come back with > a more detailed specific proposal. > > From what I've gathered so far, it really sounds like there are two > proposals within one here. > > The first is a SPIR-frontend targeting arbitrary backends. The usage > model sounds like an existing SPIR program being compiled to either > x86 (say for testing purposes) or one of the existing GPU focused > backends. To me, this sounds like the less invasive part since none > of the concerns about data layout (or lack there of) apply. By the > time we're compiling a SPIR program to a particular target, we should > be able to optimize using target specific information. My suggestion > would be to establish a new repository (hosted on llvm.org) which > holds this frontend. I have seen no reason this should live in the > main llvm or clang repositories in the discussion to date. > > The second sounds like it's a proposal to have Clang support an SPIR > backend. Exactly what form this would take appears to be really > unclear and the implications for the project have not be spelled out. > In particular, it's not clear to me that preserving all the invariants > needed to emit SPIR through the optimizer is even possible with our > current IR and type system. I would be actively opposed to seeing > changes in this direction land without substaintial further discussion > and active contribution/ownership by an existing active member of the > LLVM community. > > Philip > > On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) 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 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. Currently >> it supports SPIR-V common instructions and OpenCL specific >> instructions. Supporting of other languages is under consideration. >> >> We plan to refactor the LLVM to SPIR-V converter as a backend at >> llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this >> will result in an unconventional backend which does not use >> SelectionDAG/MC, we would like to know whether it is acceptable. We >> are open to the SelectionDAG/MC approach if the community recommends it. >> >> For the SPIR-V to LLVM converter, we are seeking suggestions on its >> proper location in the LLVM project. >> >> Any comments are welcome. Thanks. >> >> Yaxun Liu >> AMD >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev