On Tue, 3 Feb 2009, Chris Lattner wrote: > On Feb 3, 2009, at 8:48 AM, Mark Mitchell wrote: > > > Andrey Belevantsev wrote: > > > > > Obviously, a library is not enough for a heterogeneous system, or > > > am I missing anything from your description? As I know, e.g. there is > > > no device-independent bytecode in the OpenCL standard which such a > > > backend could generate. > > > > That's correct. I was envisioning a proper compiler that would take > > OpenCL input and generate binary output, for a particular target, just > > as with all other GCC input languages. That target might be a GPU, or > > it might be a multi-core CPU, or it might be a single-core CPU. > > > > Of course, OpenCL also specifies some library functionality; that could > > be provided in a library that included hand-written assembly code, or > > was generated by some non-GCC tool. > > That's an interesting and very reasonable approach to start with. However, > realize that while this will give you ability to run programs that use some of > the OpenCL language extensions, you won't be able to run any real OpenCL apps. > The OpenCL programming model fundamentally requires runtime compilation and > the kernel-manipulation library APIs are a key part of that.
Naturally the GCC implementation would include both host-side and target-side libraries, where the host-side library includes all the APIs that execute the compiler and the target-side library is like libgcc / libstdc++ / libgfortran / libgomp / ... and provides implementations of the built-in functions (when it makes sense for them to generate out-of-line calls) and any other runtime support needed for the language. (There are however probably cases when it makes sense to build the host-side library for the target as well as for the host - i.e. to build it for systems where the compiler itself is not being built, with the expectation that the kernels will either be built ahead of execution or be built via running the compilers remotely.) -- Joseph S. Myers jos...@codesourcery.com