Messages in this thread | | | Date | Fri, 03 Jul 2009 14:39:51 +0200 | From | Eric Dumazet <> | Subject | Re: [PATCH 1/2] FRV: Implement atomic64_t |
| |
Ingo Molnar a écrit : > * Eric Dumazet <eric.dumazet@gmail.com> wrote: > >> My last suggestion would be : >> >> static inline unsigned long long atomic64_read(const atomic64_t *ptr) >> { >> unsigned long long res; >> >> asm volatile( >> "mov %%ebx, %%eax\n\t" >> "mov %%ecx, %%edx\n\t" >> LOCK_PREFIX "cmpxchg8b %1\n" >> : "=A" (res) >> : "m" (*ptr) >> ); >> return res; >> } >> >> ebx/ecx being read only, and their value can be random, they are >> not even mentioned in asm constraints, so gcc is allowed to keep >> useful values in these registers. >> >> So the following (stupid) example >> >> for (i = 0; i < 10000000; i++) { >> res += atomic64_read(&myvar); >> } >> >> gives : >> xorl %esi, %esi >> .L2: >> mov %ebx, %eax >> mov %ecx, %edx >> lock;cmpxchg8b myvar >> addl %eax, %ecx >> adcl %edx, %ebx >> addl $1, %esi >> cmpl $10000000, %esi >> jne .L2 > > Ok, agreed. We dont want to inline it - cmpxchg8b is way too fat - > but your code above is a valid optimization for the out-of-line > variant as well. So i have applied it as such, will post the whole > atomic64_t series soon, after some testing.
I just changed "=A" constraint to "+A" or gcc could use %edx/%eax in "ptr" address computation. I discovered this after crashing my box :)
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |