> 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 Tue, 19 May 2015 at 11:34 Owen Anderson <resistor at mac.com> wrote:> 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 don't think the suggestion is to use SelectionDAG and friends in this target. My understanding is that this would only involve registering as a target similar to the way the CppBackend does, then invoking the code from lib/SPIRV. By registering as a target you can select SPIR-V for Clang emission the same way you select, say, X86 or ARM, rather than adding a special flag. Stefanus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/e95c7e81/attachment.html>
I agree with Owen here, this is really just a serialization of llvm IR that may or may not support various LLVM IR features. Can you give another example of something not legal in SPIR that is legal in LLVM IR that you'd still be able to/want to lower? (Bonus points, a serialization option that includes new LLVM IR features under a "next version" of SPIR :) -eric On Tue, May 19, 2015 at 8:35 AM Owen Anderson <resistor at mac.com> wrote:> > > 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 > > > > _______________________________________________ > 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/8d900adc/attachment.html>
>By registering as a target you can select SPIR-V for Clang emission the same way you select, say, X86 or ARM, rather than adding a special flag.How do you think about Combination of Backend_EmitSPIRV Action, createSPIRVWritePass and -emit-spirv command line option on clang?
Answers to Owen;>> 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.My motivation here is that a target would give us a nice logical separation - EG. these intrinsics only work with the SPIR-V target and there is no way you should be calling them from any other context. I really didn't think people would want us to add a bunch of intrinsics to Intrinsics.td.>> 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.My idea was that this would be backend ala the CppBackend, it would essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp code. The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports. As Chris said;> 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.Is exactly what I thought we'd end up with. -Neil.
On Tue, May 19, 2015 at 9:48 AM, Neil Henning <llvm at duskborn.com> wrote:> Answers to Owen; > >> 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. >> > My motivation here is that a target would give us a nice logical > separation - EG. these intrinsics only work with the SPIR-V target and > there is no way you should be calling them from any other context. I really > didn't think people would want us to add a bunch of intrinsics to > Intrinsics.td.It actually sort of makes sense to have them somewhere more generic. If you imagine a GPU driver based on LLVM, where the flow is SPIR-V -> LLVM IR -> GPU backend, then these intrinsics actually *are* going to filter down into a backend other than a "SPIR-V backend". So we have at least two use cases: 1) Frontend -> LLVM IR -> SPIR-V: primary concern is for the Frontend to generate LLVM IR that contains a subset of operations suitable for SPIR-V. 2) SPIR-V -> LLVM IR -> GPU backend: primary concern is just deserializing the darn thing. Want lib/SPIRV to just be a simple (and fast and no security vulnerabilities!) way to suck in a buffer of SPIR-V and turn it into a Module. It seems that we're getting pretty hung up on whether something in lib/Target is necessary for various random pieces of machinery for 1). E.g. in 1) are we compiling with a "spirv triple"? (is something in lib/Target needed for this?) In 2) we are definitely not compiling with a spirv triple (actually I wonder how that will work: when will the triple and datalayout and stuff get changed...; during the deserialization process?). -- Sean Silva> > 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. >> > My idea was that this would be backend ala the CppBackend, it would > essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp code. > The 'backend' in this context is purely so that we can then enable Clang to > target SPIR-V in the same consistent manner to all the other targets it > supports. > > As Chris said; > > 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. >> > > Is exactly what I thought we'd end up with. > > -Neil. > > > _______________________________________________ > 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/b59ca8b9/attachment.html>
> On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com> wrote: > > The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM. The clang driver is part of the LLVM project. If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that. If a particular frontend vendor wants to customize the flags, they can always do so themselves. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/79080dde/attachment.html>