> 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
2015-05-20 0:29 GMT+08:00 Chris Lattner <clattner at apple.com>:> >> 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. > >From my points of view, there is two different of roles along with SPIR-V.1, As a backend of clang, in this way, maybe we treat SPIR-V as a llvm backend is the easiest way to implement, but that not agree with the nature of SPIR-V, it's a IR(intermediate representation) , and Target means the machine level abstraction. Anyway, we also have Asm.js and CppBackend have same feature. 2, As a frontend IR, it's would first translate to LLVM IR, and then translate to Target Machine. So maybe we need to have two different kinds of target, One is real target like x86, x64, arm and so on. The other one is CppBackend, Asm.js SPIR-V, and maybe Java ByteCodes MSIL> -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
On 19 May 2015, at 12:40, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote:> > From my points of view, there is two different of roles along with SPIR-V. > 1, As a backend of clang, in this way, maybe we treat SPIR-V as a llvm > backend is the easiest way to implement, but that not agree with the > nature of SPIR-V, it's a IR(intermediate representation) , and Target > means the machine level abstraction. Anyway, we also have Asm.js and > CppBackend have same feature.I think that this should be generalised. It’s not just clang that is likely to be generating SPIR-V - other DSL compilers that want to run code on the GPU are likely to as well, along with existing things (I wouldn’t be surprised to see Julia generate SPIR-V, for example). There are therefore two questions: - How will clang expose this to users (cfe-dev question)? - How will SPIR generation be exposed to front-end developers in general?> 2, As a frontend IR, it's would first translate to LLVM IR, and then > translate to Target Machine.There may also be a third case of things that both consume and produce SPIR-V. Things that are the moral equivalent of linkers may fit in this, as may code obfuscation tools, and more traditional optimisers. David