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>
Hey Reid, (Donning my Khronos hat here) - it would make sense to keep the code together within a SPIRV backend, in that there are many helper constructs shared by both the reader/writer - we realised though that this would be a non-standard thing to do in terms of LLVM as it stands (EG. we have a backend that also has code that can consume SPIR-V and spit out LLVM IR!), so I am happy that you have suggested it :) -Neil. On 13/05/15 18:32, Reid Kleckner wrote:> On Wed, May 13, 2015 at 6:11 AM, David Chisnall > <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote: > > On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com > <mailto: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)? > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150514/e46cf2ad/attachment.html>
+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 forward! -Chris> On May 14, 2015, at 1:56 AM, Neil Henning <llvm at duskborn.com> wrote: > > Hey Reid, > > (Donning my Khronos hat here) - it would make sense to keep the code together within a SPIRV backend, in that there are many helper constructs shared by both the reader/writer - we realised though that this would be a non-standard thing to do in terms of LLVM as it stands (EG. we have a backend that also has code that can consume SPIR-V and spit out LLVM IR!), so I am happy that you have suggested it :) > > -Neil. > > On 13/05/15 18:32, Reid Kleckner wrote: >> On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote: >> On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com <mailto: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 <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)? >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/345c61aa/attachment.html>