This is the mail archive of the
mailing list for the GCC project.
Re: SPIR-V and GCC
- From: David Malcolm <dmalcolm at redhat dot com>
- To: BogDan <bog_dan_ro at yahoo dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 04 Mar 2015 11:43:31 -0500
- Subject: Re: SPIR-V and GCC
- Authentication-results: sourceware.org; auth=none
- References: <1425482524 dot 8624 dot 114 dot camel at surprise> <1046835188 dot 2660310 dot 1425486054471 dot JavaMail dot yahoo at mail dot yahoo dot com>
On Wed, 2015-03-04 at 16:20 +0000, BogDan wrote:
> On Wednesday, March 4, 2015 5:22 PM, David Malcolm <email@example.com> wrote:
> On Wed, 2015-03-04 at 14:36 +0000, BogDan wrote:
> > Hello folks,
> > Probably is a little bit too early, but I'd like to ask if there is
> > any chance to use gcc to produce SPIR-V .
> > It will be just great if we'll be able to write our shaders in e.g.
> > C/C++/(any language supported by gcc) and use GCC to compile them as
> > SPIR-V!
> > It will be fantastic to use only one compiler collection for CPU and
> > for GPU compute&graphics!
> > Cheers,
> > BogDan.
> >  https://www.khronos.org/registry/spir-v/
> I work on gcc, but in a former life I was a game developer , so this
> piqued my interest :)
> WOW you've work on AVP!
[for only about a month or so iirc, mostly just salvaging some of my UI
code from a never-published space trading/combat game, fwiw :)]
> A few questions:
> (A) Does SPIR-V have an assembler? The URL you posted talks about it
> being a binary format, but the example in there shows a "disassembled"
> textual form. The reason I ask is that the internals of gcc's backend
> expect to be writing out "assembler", which then goes through an
> assembler program to produce a binary. In theory I guess one could have
> the "assembler" format generated by the backend be binary, but it's
> likely to be *much* easier to hack on if there's an intermediate textual
> SPIR-V it's an Intermediate Language binary format. First versions were
> based on LLVM. SPIR-V has nothing to do with the old SPIR implementations,
> but for some reason khronos decide to keep the name :)
> This http://www.g-truc.net/post-0714.html great article explans better
> what SPIR-V is.
> (B) Are you thinking about this for primarly ahead-of-time
> compilation, or are you interested in just-in-time compilation to
> SPIR-V? I ask since I maintain the new "libgccjit" feature in GCC 5.
> One of the current assumptions in libgccjit is that host==target, but I
> hope to relax that for gcc 6 so that libgccjit could e.g. generate code
> for a GPU. Another gcc 6 possibility could be multi-target support for
> libgccjit, so that you can populate a gcc_jit_context with code, then
> have it generate machine code for both the CPU and for the GPU (mostly
> just thinking aloud here).
> Even though most of the people will use it for ahead-of-time compilation,
> but IMHO it can be both!
Another use-case that occurred to me when I was looking at the link you
posted above: using gcc for optimizing SPIR-V and compiling it e.g. to
As of gcc 5, libgccjit can be hooked up to a pre-existing language
frontend, with the gcc backend emitting machine code for the CPU,
assuming that the frontend is license-compatible with libgccjit's
GPLv3-or-later. See this example, which uses libgccjit to build a
compiler for brainf**k:
So if there's a SPIR-V loader library that's license-compatible, you
could write code to inject SPIR-V into libgccjit, and call
gcc_jit_context_compile_to_file on it to optimize it and turn it into
That use-case is probably doable today using gcc 5 (and could be written
in C, C++, Python, or D, with the bindings we already have).
Potentially such a library could also generate other kinds of code,
including e.g. optimized SPIR-V... but that requires both (i) a gcc
backend for the desired target code and (ii) libgccjit to support
cross-compilation (which as I mentioned would probably be a gcc 6
> (C) (probably most important) Is a SPIR-V backend something you'd be
> up for working on? Any other volunteers out there?
> (Maybe a GSoC thing?)
> Personally, I never touched gcc source code before, and I don't have
> any idea about (any) compilers internals (thought I have experience
> working for free software projects ). Anyway I think it will be a
> great experience to (at least try to :) ) help in my spare time.
> A GSOC project is a great idea as well!
I'm probably not the best person to help, as I've not written a gcc
backend (the jit counts as a frontend, albeit a very unusual one). FWIW
there seems to be a good tutorial on writing backends here:
> P.S. Sorry for the inline reply, I had to use yahoo mail and ...
>  http://blog.qt.io/blog/2012/11/08/necessitas-android-port-contributed-to-the-qt-project