As you may have noticed, we are currently experiencing linker problems on
ARM, where the ldexp test case is failing. I investigated; the cause is the
following:
(1) Name mangling of functions depends on the types of the function
arguments. It does not depend on the actual sizes (32 or 64 bits) of these
arguments. int, long, and long long are mangled via the lower-case letters
i, l (ell), and x, respectively.
(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?
(3) This has two consequences. The first is that passing "long" from OpenCL
C to "long" in C++ (e.g. to a kernel library routine) is accepted by the
linker, although it will fail horribly at run time (data corruption or
segfault.) Not good, but then, this is just an undetected error, so we can
live with this.
(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.
I know of no good solution.
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.
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.
I suggest option (b) as a short-term fix. We can do (c), which is merely
tedious,
-erik
PS: Actually, it seems as if "long long" was already supported in OpenCL
C...
--
Erik Schnetter <[email protected]>
http://www.perimeterinstitute.ca/personal/eschnetter/
------------------------------------------------------------------------------
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
