> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V target allows Clang and other LLVM front ends to target generic OpenCL/Vulkan platforms.I don’t think Chris was suggesting lib/Bitcode/SPIRV. That wouldn’t make a lot of sense, since Bitcode != SPIR-V. FWIW, I agree with Chris that it makes sense as a parallel to lib/Bitcode. SPIR-V is (almost) an alternate encoding of LLVM IR, with a few things added/removed, and it makes sense to treat it in a similar manner to our normal serialization format. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150517/42a98623/attachment.html>
I agree :) I also think it should be something like lib/SPIRV . And like Chris B. I'm also very interested to see it in! :) Marcello 2015-05-17 0:13 GMT-07:00 Owen Anderson <resistor at mac.com>:> > On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept > at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do > conversions between LLVM and SPIR-V. On the other hand, we create a > llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. > The SPIR-V target allows Clang and other LLVM front ends to target generic > OpenCL/Vulkan platforms. > > > I don’t think Chris was suggesting lib/Bitcode/SPIRV. That wouldn’t make > a lot of sense, since Bitcode != SPIR-V. > > FWIW, I agree with Chris that it makes sense as a parallel to > lib/Bitcode. SPIR-V is (almost) an alternate encoding of LLVM IR, with a > few things added/removed, and it makes sense to treat it in a similar > manner to our normal serialization format. > > —Owen > > _______________________________________________ > 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/20150517/8308b262/attachment.html>
On Sun, May 17, 2015 at 12:13 AM, Owen Anderson <resistor at mac.com> wrote:> > On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept > at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do > conversions between LLVM and SPIR-V. On the other hand, we create a > llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. > The SPIR-V target allows Clang and other LLVM front ends to target generic > OpenCL/Vulkan platforms. > > > I don’t think Chris was suggesting lib/Bitcode/SPIRV. That wouldn’t make > a lot of sense, since Bitcode != SPIR-V. > > FWIW, I agree with Chris that it makes sense as a parallel to > lib/Bitcode. SPIR-V is (almost) an alternate encoding of LLVM IR, with a > few things added/removed, and it makes sense to treat it in a similar > manner to our normal serialization format. > > >From an end-user's perspective it sounds like the use case for SPIR-Vthough is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV). So it sounds like having some "target-like" component for SPIR-V will be necessary to ease integration with regular clang flow. It might be that we have generic SPIR-V support factored out into lib/SPIRV, and then lib/Target/SPIRV for the logic that integrates with clang. -- Sean Silva> —Owen > > _______________________________________________ > 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/20150518/4643dce5/attachment.html>
> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Sun, May 17, 2015 at 12:13 AM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote: > >> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com <mailto:Yaxun.Liu at amd.com>> wrote: >> >> I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V target allows Clang and other LLVM front ends to target generic OpenCL/Vulkan platforms. > > I don’t think Chris was suggesting lib/Bitcode/SPIRV. That wouldn’t make a lot of sense, since Bitcode != SPIR-V. > > FWIW, I agree with Chris that it makes sense as a parallel to lib/Bitcode. SPIR-V is (almost) an alternate encoding of LLVM IR, with a few things added/removed, and it makes sense to treat it in a similar manner to our normal serialization format. > > > From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV). > > So it sounds like having some "target-like" component for SPIR-V will be necessary to ease integration with regular clang flow. It might be that we have generic SPIR-V support factored out into lib/SPIRV, and then lib/Target/SPIRV for the logic that integrates with clang.I agree. I haven’t looked in to the SPIRV spec, but if its only intended to support GPU graphics/compute workloads then i doubt it supports everything the IR bitcode/ll code supports. That makes it feel more like a target to me. That is, is it appropriate to add lib/SPIRV as a serialization format when it doesn’t support all of LLVM IR? Targets can crash if they are fed code they don’t support, but I don’t like the sound of the file emitter crashing because the IR contained a function pointer. BTW, i’m not arguing against SPIRV in LLVM. I think it would be a great addition, just that we should be careful in making sure that everyone is ok with it not supporting all IR constructs but still being a first class serialization format. Cheers, Pete> > -- Sean Silva > > —Owen > > _______________________________________________ > 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/20150518/e8771e31/attachment.html>
> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com> wrote: > > From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV). >SPIR-V is a serialization format between the user’s frontend and the vendor’s backend. From the user’s perspective, it looks like a target. From the vendor’s perspective, it looks like a frontend. In this sense, it is very comparable to LLVM bitcode itself. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/48d5323f/attachment.html>
On 17 May 2015 at 00:13, Owen Anderson <resistor at mac.com> wrote:> > On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept > at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do > conversions between LLVM and SPIR-V. On the other hand, we create a > llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. > The SPIR-V target allows Clang and other LLVM front ends to target generic > OpenCL/Vulkan platforms. > > > I don’t think Chris was suggesting lib/Bitcode/SPIRV. That wouldn’t make > a lot of sense, since Bitcode != SPIR-V. > > FWIW, I agree with Chris that it makes sense as a parallel to > lib/Bitcode. SPIR-V is (almost) an alternate encoding of LLVM IR, with a > few things added/removed, and it makes sense to treat it in a similar > manner to our normal serialization format. >What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get identical .bc back? Can I take spir-V -> .bc -> spir-V and get identical spir-V back? If both of these are not true, in what way is it a serialization format? Or put another way, even if we call it a serialization format, it wouldn't be a serialization format of LLVM IR. Note that even the CPPBackend is in lib/Target, and that does guarantee perfect round-trip reproduction of everything in LLVM IR, while SPIR-V afaik does not. If it makes sense share to share code (opcode tables, etc.) between the spir-v frontend and backend, then I have no real problem putting them in a single directory. I just want it to be clear that we can continue to freely evolve LLVM IR and that there may be explicit steps to convert future LLVM IR to SPIR-V and vice versa, and a place to put that code. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/9a7f61c3/attachment.html>
> On May 19, 2015, at 6:04 PM, Nick Lewycky <nlewycky at google.com> wrote: > > What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get identical .bc back?For the subset of LLVM IR that is representable in SPIR-V, I would expect this to work. Given that SPIR-V is specialized for representing a particular kind of programming model, that seems completely reasonable to me.> Can I take spir-V -> .bc -> spir-V and get identical spir-V back?I would expect this to work as well. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150520/3c0ccffa/attachment.html>