lkml.org 
[lkml]   [2009]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2009-07-03 14:43    [W:0.189 / U:0.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site