Also, is it worthwhile putting a prfm before the ldaxr. EG
There is already a thread upstream about this: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00508.html
I reject adding this to -mcpu=generic as it will hurt ThunderX more than it will help. Prfm is single issue for ThunderX so it causes an extra cycle for each case. For the kernel, the pfrm really should be patched out for ThunderX; I will propose a patch for that later on. The way ThunderX implements ldxr/stxr is much simpler than say Cortex-a57/a72 because the inner and outer domains are the same aka there is will only be one coherent point, the L2. It is also why ThunderX exposes so many race conditions (well and the timeout for write going to the coherent point is around 1024 cycles if there was no flush).
Thanks, Andrew Pinski
-----Original Message----- From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Edward Nevill Sent: Wednesday, March 9, 2016 5:02 AM To: Linaro Toolchain Mailman List linaro-toolchain@lists.linaro.org Subject: Some questions about the gcc __sync intrinsics
Hi,
I have been comparing the stock gcc 5.2 and the Linaro 5.2 (Linaro GCC 5.2-2015.11-1) and have noticed a difference with the __sync intrinsics.
Here is the simple test case
--- cut here --- int add_int(int add_value, int *dest) { return __sync_add_and_fetch(dest, add_value); } --- cut here ---
Compiling with the stock gcc 5.2 (-S -O3) I get
--------- add_int: .L2: ldaxr w2, [x1] add w2, w2, w0 stlxr w3, w2, [x1] cbnz w3, .L2 mov w0, w2 ret ---------
Wheras with Linaro gcc 5.2 I get
--------- add_int: .L2: ldxr w2, [x1] add w2, w2, w0 stlxr w3, w2, [x1] cbnz w3, .L2 dmb ish mov w0, w2 ret ---------
Why the extra (unnecessary?) memory barrier?
Also, is it worthwhile putting a prfm before the ldaxr. EG
add_int: prfm pst1strm, [x1] .L2: ldaxr w2, [x1]
See the following thread
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355996.html
All the best, Ed _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain