Pekka
I committed a slightly modified version of your patch to Vecmathlib.
Do you have a Bitbucket account? I can give you write access to Vecmathlib.
I am quite sure that the representations are compatible, and that memcpy is
the right thing to call. In OpenCL, one could also use a union instead, and
this is indeed done in the "as_type" functions. In C++, unions are not
guaranteed to work in this way, but memcpy is. Since we use the same
compiler (llvm) in both cases, I really expect things to work, unless llvm
does something funny with certain vector types that don't match the
hardware (e.g. float2 or double3).
The failures above look as if something went wrong with the low-order
floating-point bits, indicating a rounding problem. Since this test case is
about rounding, I suspect that Vecmathlib rounds the wrong way. Vecmathlib
has an extensive test suite for testing rounding, but this is based on
checking with random numbers, and it may be that I missed some
unlikely-yet-important corner cases. I'll have a closer look.
-erik
On Tue, Mar 19, 2013 at 9:22 AM, Pekka Jääskeläinen <
[email protected]> wrote:
> OK,
>
> Vecmathlib mode does not crash the compilation but the tests
> fail with wrong results and even hangs. You can see it when
> running the convert_types test by hand:
>
> kernel/kernel test_convert_type
> ...
> FAIL: convert_ulong16_rte((float16)) - sample#: 14 element#: 4 expected:
> 0x0000000000000002 actual: 0000000000000000
> FAIL: convert_ulong16_sat_rte((**float16)) - sample#: 14 element#: 0
> expected: 0x00038d7ea4000000 actual: 0x00038d7eac000000
> FAIL: convert_ulong16_rtp((float16)) - sample#: 14 element#: 4 expected:
> 0x0000000000000002 actual: 0000000000000000
> FAIL: convert_ulong16_sat_rtp((**float16)) - sample#: 14 element#: 0
> expected: 0x00038d7ea4000000 actual: 0x00038d7e9c000000
> FAIL: convert_ulong16_rtn((float16)) - sample#: 14 element#: 4 expected:
> 0x0000000000000001 actual: 0000000000000000
> FAIL: convert_ulong16_sat_rtn((**float16)) - sample#: 14 element#: 0
> expected: 0x00038d7ea4000000 actual: 0x00038d7eac000000
> FAIL: convert_ulong16_rte((float16)) - sample#: 15 element#: 4 expected:
> 0x0000000000000002 actual: 0000000000000000
> FAIL: convert_ulong16_rtp((float16)) - sample#: 15 element#: 4 expected:
> 0x0000000000000002 actual: 0000000000000000
> FAIL: convert_ulong16_rtn((float16)) - sample#: 15 element#: 4 expected:
> 0x0000000000000001 actual: 0000000000000000
>
>
>
> Hangs here. The convert type implementations call some of
> the VML functions.
>
> My first suspicion is the conversion routine between
> the VML vector datatypes and the pocl's which is done with
> a memcpy. Erik, are you sure it is a 1:1 match and copying like
> this is safe?
>
> Attached is a patch to VML which adds prefixes to functions
> which need them (to avoid using the std C functions that get
> converted to LLVM intrinsics in the frontend).
>
>
>
> On 03/13/2013 04:27 AM, Erik Schnetter wrote:
>
>> would be compiled when pocl is built, creating bc files. When kernels
>> are compiled, these bc files are used.
>>
>
>
> --
> --Pekka
>
--
Erik Schnetter <[email protected]>
http://www.perimeterinstitute.ca/personal/eschnetter/
AIM: eschnett247, Skype: eschnett, Google Talk: [email protected]
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
