[Gc] Re[2]: libatomic_ops aarch64 support

Ivan Maidanski ivmai at mail.ru
Tue Feb 12 13:04:34 PST 2013


 Hi Yvan,

Sunday, 10 Feb 2013, 21:45 +01:00 from Yvan Roux <yvan.roux at linaro.org>:
>Hi Ivan,
>
>> 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_atomic_pthreads succeeds
>test_malloc and test_stack abort
>
>here are the raw results :
>
>root at genericarmv8:/home/test# ./test_atomic
>Missing: AO_short_store
>Missing: AO_short_load
>Missing: AO_short_fetch_and_add
>Missing: AO_short_fetch_and_add1
>Missing: AO_short_fetch_and_sub1
>Missing: AO_char_store
>Missing: AO_char_load
>Missing: AO_char_fetch_and_add
>Missing: AO_char_fetch_and_add1
>Missing: AO_char_fetch_and_sub1
>Missing: AO_int_store
>Missing: AO_int_load
>Missing: AO_int_fetch_and_add
>Missing: AO_int_fetch_and_add1
>Missing: AO_int_fetch_and_sub1
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
>Testing add1/sub1
>Succeeded
>Testing store_release_write/load_acquire_read
>Succeeded
>Testing test_and_set
>Succeeded
>
>root at genericarmv8:/home/test# ./test_malloc
>Performing 1000 reversals of 100 element lists in 3 threads
>Testing AO_malloc/AO_free
>First large allocation smashed
>First large allocation smashed
>Aborted
>
>root at genericarmv8:/home/test# ./test_stack
>Found duplicate list element 1
>Aborted
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 :
>
>AO_nop_read:
>        dmb     ishld    // inner shareable load before load and load
>before store
>        ret
>
>AO_nop_write:
>        dmb     ish      // inner shareable any before any
>        ret
To my understanding, AO_nop_write should be defined as "dmb st". May be, I'm wrong. Help of the community is really appreciated!

>
>
>AO_nop_full:
>        dmb     ish
>        ret
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).

>
>
>http://www.linaro.org/engineering/armv8
>
>> 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.

Regards,
Ivan
>
>
>> Thank you. Sorry for a delay with the answer.
>
>No problem, many thanks
>
>Cheers,
>Yvan
>
>> Regards,
>> Ivan
>>
>> 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.
>>
>> Cheers,
>> Yvan
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130213/de787490/attachment.html


More information about the Gc mailing list