22.4.2015, 15:23, Tiago Gehring kirjoitti: > I was indeed referring to building libpocl.a and not the LLVM > static-link option. But regarding the latter though, I never thought > about the LLVM headers and other dependencies. Thanks for pointing this > out to me! I thought that the linking with LLVM statically would create > a self-contained binary, but if there are still dependencies such as > LLVM headers for the compilation of OpenCL kernels then I have to > re-think my approach and forget about the static linking of LLVM. In > this case it will have to be installed on the target machine system-wide > no matter what; I can live with that since it is quite standard. Having > it as a pre-requisite is still much better than asking for people to > install and mess with Intel's or AMD's binary OpenCL runtime.
The idea of bundling LLVM with libpocl so create a self-contained statically linked binary has been discussed in the past, and it has progressed somewhat as now pocl mostly calls LLVM/Clang at the library level. I don't believe there are dependencies to LLVM headers during kernel compilation, but the problem is that pocl still depends on the Clang command line binary for the very final binary linkage stage of the kernel compilation. It needs to be converted to API calls to avoid the need for an Clang/LLVM installation in the system. > The only problem with not being able to control LLVM's version and using > the system one is that it probably undermines my previous idea of > pre-compiling the *.bc kernel files one one machine and shipping it with > my application, since I'm not expecting them to be compatible across > different LLVM versions. But perhaps I can pre-compile the *.bc files > for each major LLVM version (assuming that the code is binary compatible > between LLVM's minor versions). I have to think about that since it is > becoming more complicated that I thought. Perhaps going for one of > Pekka's suggestions would be really the best idea (although I'm really > not sure if I will have the required time or knowledge to implement it - > I'm really not familiar with the code and would require a lot of time to > get familiar with it I guess). Bitcode files are compatible between minor versions. However, even though we still support as old as Clang/LLVM version 3.2, with pocl the recommendation is to use the newest Clang possible as they usually have more OpenCL C language support/fixes and better vectorization etc. than the older ones. But in the longer run I think install-time or on-demand rebuilding of the kernel builtin bitcode (or even always picking them up from sources) is the way to implement this "bundling" use case also. -- Pekka ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
