I can reproduce test suite failures on my system (OSX, x86_64), but no
hangs. Also, vecmathlib does not have loops that could lead to a hang.
I notice that all failures are for vector datatypes that are 32 bytes long
(short16, int8, long4, float8, double4). This is very suspicious, since the
implementation of convert_type does not depend on this size. I also notice
that the AVX vector instructions provide 32-byte vectors, but are very
difficult to use for integer vectors. Could this be an LLVM code generation
issue?
I am using llvm-3.2, built myself, and using "-march=corei7-avx" as target
architecture.
-erik
On Tue, Mar 19, 2013 at 2:12 PM, Erik Schnetter <
[email protected]> wrote:
> 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
>>
>
> I believe this fails because e.g. convert_ulong16_rte (the first failing
> function) is based on two calls to convert_ulong8 (without the _rte
> suffix). On the other hand, I think that _rte is the default behaviour, so
> this could be fine.
>
> This is ultimately implemented via a scalar function convert_ulong, which
> evaluates "(ulong)x". This does not invoke Vecmathlib.
>
> -erik
>
> --
> Erik Schnetter <[email protected]>
> http://www.perimeterinstitute.ca/personal/eschnetter/
> AIM: eschnett247, Skype: eschnett, Google Talk: [email protected]
>
--
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
