Thanks Pekka. I think that I will not give up on my idea of a fully
contained pocl library (i.e. all static LLVM and libclang) after all then
(or at least leave it as an alternative). How difficult do you think would
it be to replace the clang binary calls by library ones?

And regarding the other question (about the compilation of the *.bc files)
I agree with you that in the long run the rebuilding of the kernel bitcode
(or getting rid of it altogether) is a good idea. Are any LLVM (or other)
external headers
required to compile the kernel bitcode?

Thanks again,
Tiago

On Wed, Apr 22, 2015 at 3:04 PM, Pekka Jääskeläinen <
[email protected]> wrote:

> 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
>
------------------------------------------------------------------------------
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

Reply via email to