From: Carlos S. de La L. <car...@ur...> - 2011-11-09 12:44:01
|
Ok, i inline your "post" in the blueprint here: > Requiring Newlib to be in device/host produces more trouble. A point in embedding the required functions inside pocl is to make pocl self-contained (aside from the LLVM/Clang dependency), that is, to make it easily portable to various platforms (hosts and devices) + the inlining benefits. I just got rid of the gcc dependency in the 'ld' branch and I'd like to get rid of the libm dependency (were it the Newlib or the native) too. There is no need to include newlib on the host. I was thinking already on this wen I proposed it. Newlib would be needed only at pocl compile time, then (some of) the kernel libraries link against them, in bytecode, producing self-contained kernel libraries with no external requirements. > Newlib is quite big and contains the whole C library which pocl does not need. It would require porting the whole newlib to the target under question whenever one wants to use pocl on a host/device. I see that quite a bit more "overkill" than just copying the functions we need from some BSD/MIT licensed library, if one is found. Not really. newlib works using stubs so you need to port nothing, some of the functions will have unresolved stubs but we wont be using those. Only the needed functions (say sin/cos/whatever) will get linked (library behaviour). Basically it is the same as "borrowing" the sources, but at bytecode level. > Anyways, it seems the math lib of Newlib is nicely separable so we could include it in pocl to avoid the requirement of Newlib installed? The license is a bit unclear but I think it's a BSD license for the libm part. We could just copy the 'math' dir from the Newlib to the source tree and then the various kernel lib implementations can cherry pick the codes they need from there (at source code level due to the different bitcode targets). I do not like the idea of taking code of of there, for several reasons: 1) It is kind of "wrong", even when licenses allow it. If someone used pocl for example I would prefer them to use pocl than getting the passes out of llvmopencl directory and using it in their own project. If you take part of a project code base you do not support the project. 2) It requires "mimicing" some of the configure / makefile structure of newlib, configure switches, etc. Why reinventing the wheel? They give some source files with the build framework, let us use it. The reasons would of course be seen as "weak" if there was a "strong" reason against them, but the linking approach is a cleaner alternative IMO. > A major point IMHO for the "inlineable versions by default" is the exploitation inter-WI parallelism with vectors or long instructions which is ruined if you have a libary call in the kernel. Avoiding such can lead to a more parallelizable default generic lib (ability to maybe execute some parts of sin/cos, for example, for multiple WIs using parallel instructions) which should be a good in the "performance portability" sense. Of course, that is pretty clear. The point is if we do not include newlib in the pocl (which I am against) then making the default library depend on it might be a drawback, given that the builtins are also "standard". However I am not so strongly about it, newlib (or any other C-lib) build-time dependency is not a big deal. > So. I propose: > 1. Copy the required math implementations from Newlib > 2 .Use them in the generic implementation and assume the device-optimized libs use whatever is better for them I would say: 1. Compile newlib to bytecode (I guess CC=clang CFLAGS=-ccc-target-triplet=xxx is probably enough) 2. Make either default or per-device libs link against that and perform a library linking step to parts of the C-library being used in the kernel library get linked in creating a self contained kernel runtime library. Carlos |