[Gc] Re: libatomic_ops aarch64 support
ivmai at mail.ru
Tue Feb 12 13:04:34 PST 2013
Sunday, 10 Feb 2013, 21:45 +01:00 from Yvan Roux <yvan.roux at linaro.org>:
>> I've updated the files in add-aarch64-support branch - please retest it.
>test_atomic fails on the AO_double_load test
What's the asm output for double_load? (in arm.h, you could see the implementation for 32-bit ARM)
>test_malloc and test_stack abort
>here are the raw results :
>root at genericarmv8:/home/test# ./test_atomic
It is ok for missing AO_char/short/int - I'll implement them using template header.
>Assertion failed test_atomic_include.h:249 (barrier: )
What's the returned value of double_load?
>root at genericarmv8:/home/test# ./test_atomic_pthreads
>root at genericarmv8:/home/test# ./test_malloc
>Performing 1000 reversals of 100 element lists in 3 threads
>First large allocation smashed
>First large allocation smashed
>root at genericarmv8:/home/test# ./test_stack
>Found duplicate list element 1
As I understand, you tested your first AArch64 implemented (that you submitted to me), right?
If so, could you please identify some my commit that breaks test_malloc/stack?
>> Also I'd like to know asm generated for AO_nop_* primitives (I've changed
>> __sync_synchronize to __atomic_thread_fence) and AO_double_* primitives.
>here is the generated code :
> dmb ishld // inner shareable load before load and load
> dmb ish // inner shareable any before any
To my understanding, AO_nop_write should be defined as "dmb st". May be, I'm wrong. Help of the community is really appreciated!
> dmb ish
Is this the same (or stronger) as for __sync_synchronize?
>> Please rewrite CAS primitives (for AO_t and AO_double_t, relaxed and
>> acquire/release/full variants) using __atomic_compare_exchange_n.
>ok fine, I will do it.
>> Q: Which compiler version do you use?
>I use for the cross compiler the
>gcc-linaro-aarch64-linux-gnu-4.7-2013.01, I use my own build, but you
>can find the binary release on the Linaro engineering armv8 page in
>the download section (link below), and a 2012.12 native release (the
>one shipped with the vexpress64-openembedded_sdk image) and with this
>one the add-aarch64-support branch build failed during the compilation
>of atomic_ops.c with the error:
>atomic_ops.c:96:1: error: unknown type name 'AO_TS_t'
Strange. This should be defined as AO_t in test_and_set_t_is_ao_t.h (please check preprocessed code).
>> In case you have more free time (and wish to check some other targets), it
>> would be good to check whether it is ok to use gcc/generic.h (starting from
>> some GCC version) instead of asm-based primitives in gcc/*.h (by
>> eye-inspection of asm code generated for the target comparing it to the
>> instructions written in gcc/*.h files).
>I don't guarantee that I will check all the targets, but will give a look ;)
Thank you. I think it would be better to understand/fix the problems with AArch64 first.
>> Thank you. Sorry for a delay with the answer.
>No problem, many thanks
>> Fri, 8 Feb 2013, 16:53 +01:00 from Yvan Roux < yvan.roux at linaro.org >:
>> Hi Ivan,
>> Do you need more inputs regarding the aarch64 support, I didn't had
>> time to work on this topic during the past weeks, but as I have a slot
>> dedicated to that during the coming one, it would be great if you tell
>> me what I can do.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc