From: Pekka J. <pek...@tu...> - 2011-12-19 09:21:43
|
Hi, I think you missed this: >> Although I'd like to cache the final >> binary, not only the bitcode I meant to (also) cache (or store in the binary format) the code gen results, i.e., the final bits. As you know, for TCE it might take considerable time to generate the code from the bitcode. Also, in general, in a production system that uses OpenCL for the program, we do not want to execute the compiler at all if one can avoid it. We might even exclude the compiler from the host to provide something like the "standalone mode" (to ship binaries only) but in a more standards compliant way. Useless overhead is useless overhead. It's especially the case for mobile devices with energy constraints. All in all, I don't think there's many cases when you do *not* want caching (even over multiple OpenCL program runs). If it works "behind the scenes" like ccache (and includes the pocl+LLVM versions in the hash) it should always be beneficial. Disk space is cheap. I think clCreateProgramWithBinary can also contain all this functionality for manual caching: "The program binary can consist of either or both: Device-specific code and/or, Implementation-specific intermediate representation (IR) which will be converted to the device-specific code." "OpenCL allows applications to create a program object using the program source or binary and build appropriate program executables. This can be very useful as it allows applications to load program source and then compile and link to generate a program executable online on its first instance for appropriate OpenCL devices in the system. These executables can now be queried and cached by the application. Future instances of the application launching will no longer need to compile and link the program executables. The cached executables can be read and loaded by the application, which can help significantly reduce the application initialization time." BR, -- Pekka |