From: Carlos S. de La L. <car...@ur...> - 2011-12-19 10:18:57
|
>>> 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. Ok, I had actually missed it. Then some binary format is needed, I think we can reuse AMD one (just uses ELF sections for different binaries) as it is well specified. > 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. Binary caching is probably always OK. I was referring to storing replicated WG functions in the same LLVM IR module when I said it has drawbacks. > 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." Yep, binary format is really implementation dependent so you can put whatever you want there. The point is in our case we always need the LLVM IR, cause while OpenCL API allows storing only the binary for a device (AMD SDK can do this, and gives an "invalid device" error of loading a binary for a different architecture) in our case storing the binary would mean fixing also the dimensions, which is not API compliant in the general cases AFAIK. Carlos |