On 06/12/2014 03:26 AM, Erik Schnetter wrote: > (2) OpenCL C specifies that the type long has 64 bits. This is > incompatible with a system's ABI for 32-bit systems, such as ARM. In > effect, this requirement defines a new, OpenCL-only ABI for 32-bit > systems. This is a known issue with OpenCL C... Maybe SPIR offers some > more wisdom here?
SPIR defines that only the built-in functions are mangled as only they can be overloaded. Other functions such as own helper functions are not mangled. The mangling scheme is documented. It defines "long long" is not valid in the mangling scheme. > (4) On the other hand, passing "long" from OpenCL C to "long long" in > C++ -- which is fine, because both map to the same machine type! -- is > rejected by the linker, since they are mangled differently. This is the > problem we are currently encountering. Could it be possible to just ensure there is no linkage of VML needed, i.e., get everything of VML inlined to the pocl's built-in function interfaces? > It may be possible to tinker with LLVM's name mangling rules, i.e. to > bend them for OpenCL C so that they match a system's ABI. I don't know > whether this is feasible. I think it's preferable to follow the SPIR mangling for OpenCL C built-in functions to move towards the SPIR support. > In the mean time, we can either (a) disable support for "long" (and > "double") on such systems, or (b) disable Vecmathlib there , since it is > written in C++, or (c) write C wrapper routines for the C++ wrapper > routines (sic!), using a manual name mangling scheme there. > > A fourth option (d) would be to add support for "long long" to OpenCL C > in Clang, making it the same type as long. We can then use long long to > interoperate with C++ to implement kernel functions. What about (potential) systems where 'long long' is not 'long' in C/C++? An additional problem is the fact that OpenCL C has fixed width types and C/C++ doesn't. > I suggest option (b) as a short-term fix. We can do (c), which is merely > tedious, It's better to be correct, so I vote (b) for the short-term, until a robust way to interface with VML is found. -- --Pekka ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
