> 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>
The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned). I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me! Cheers, -Neil. On 19/05/15 00:24, Owen Anderson wrote:> >> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com >> <mailto: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 > > > _______________________________________________ > 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/20150519/c430dc03/attachment.html>
Pierre-Andre Saulais
2015-May-19 09:45 UTC
[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter
Indeed, SPIR-V not being a target would prevent using clang to generate SPIR-V (which target triple would be used?) On the other hand, maybe it would be possible to have a clang target without a corresponding LLVM target. I'm not familiar with the target machinery in clang so I don't know if it would work or not. Either way, I don't think any LLVM tool should output SPIR-V directly, except maybe a simple conversion tool between the two IRs. Pierre-Andre On 19/05/15 09:25, Neil Henning wrote:> The problem is - as Sean and Pete (and others before) have pointed > out, from a users perspective they'll want to say 'clang make me > SPIR-V'. There are things in SPIR-V that are not representable by the > LLVM IR, so we'd have to add SPIR-V specific intrinsics for this > (again making the case for having it as a target more palatable), and > also there are things in the IR that won't be allowed when producing > SPIR-V (off the top of my head, in a graphics shader with logical > addressing mode a ton of pointer use is banned). > > I think what Sean suggested of having a very thin backend that > satisfies what a user will want when producing SPIR-V + setting up the > target specific intrinsics, and then the majority of the actual SPIR-V > production code being in lib/SPIRV sounds like a good approach to me! > > Cheers, > -Neil. > > On 19/05/15 00:24, Owen Anderson wrote: >> >>> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com >>> <mailto: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 >> >> >> _______________________________________________ >> 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/da0d8dd8/attachment.html>
> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’.The *entire point* of my email was that that is only one of two use cases of SPIR-V. As I said above, it’s a serialization format between a frontend and a backend, which means that for some clients it is an output format and for others it’s an input format. It’s also likely that SPIR-V to SPIR-V translators will exist in the future.> There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),Why does that motivate it being a target? Intrinsics do not have to be linked to a target.> and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).Again, why does that motivate it being a target? No amount of legalization can define away fundamentally unsupported major constructs. More generally, making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend. You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available. You do not want to leverage any of the general target architecture. I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a “for graphics” qualifier tacked on. —Owen
> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned). > > I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me!There are two different things going on here: 1) Where the code lives in the llvm tree. 2) How clang and other tools expose it to users. Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer. It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it. Per #2, that is a discussion for the clang lists. -Chris