Hi! On Fri, 6 Mar 2015 15:23:21 +0000 (UTC), BogDan <bog_dan...@yahoo.com> wrote: > > This http://www.g-truc.net/post-0714.html great article explans better > > what SPIR-V is.
Note that I don't know anything about SPIR-V, and I'm currently too busy to learn about it, but: > I checked them a little bit and I'm afraid it might be a a few problems to > create a SPIR-V backend: These look -- at least superficially -- similar to issues we (that is, primarily Bernd, CCed) faced, when creating a Nvidia PTX backend (primarily for offloading use, as part of the OpenACC project we're currently working on). > 1. SPIR-V a binary Intermediate Language format but it's still not machine > code. It seems gcc backends produces a text machine code, so I think will not > be possible to produce SPIR-V a binary format directly from GCC backend. (Not a problem for text-based PTX.) Indeed I don't know if it's feasible to have GCC backends generate output in a binary format -- but then, I don't think this is a show-stopper? I'm assuming that any binary format can be represented in a textual format, and then converted into the desired binary format by an "assembler"? > 2. Because SPIR-V is not a machine format, it doesn't have any registers. > Instead it's using IDs for everything [1]. I didn't find a way to create IDs > instead of registers in GCC. > [1] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_instructions In the nvptx backend, we currently disable all register allocation, under the assumption that there is an unbounded register file, with the registers having arbitrary names -- does that match the SPIR-V model? > 3. SPIR-V supports some "non-standard" types[2], will it be a problems to > support these types in GCC frontend/backend? > [2] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_types Certainly GCC can be taught about "non-standard" types, but you'll have to see at which stage of the compilation process this is best done. Grüße, Thomas
signature.asc
Description: PGP signature
