[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B6E1DA3.50204@zytor.com>
Date: Sat, 06 Feb 2010 17:55:47 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Borislav Petkov <bp@...64.org>
CC: Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Wu Fengguang <fengguang.wu@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Jamie Lokier <jamie@...reable.org>,
Roland Dreier <rdreier@...co.com>,
Al Viro <viro@...IV.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>, Brian Gerst <brgerst@...il.com>
Subject: Re: [PATCH 2/5] bitops: compile time optimization for hweight_long(CONSTANT)
On 02/06/2010 01:36 AM, Borislav Petkov wrote:
>
>> c) You call a C function, but you don't clobber the set of registers
>> that a C function would clobber. You either need to put the function in
>> an assembly wrapper (which is better in the long run), or clobber the
>> full set of registers that is clobbered by a C function (which is better
>> in the short term) -- which is eax, edx, ecx on 32 bits, but rax, rdi,
>> esi, rdx, rcx, r8, r9, r10, r11 on 64 bits.
>
> I think you mean rsi instead of esi here.
>
> Well, the example Brian pointed me to - __mutex_fastpath_lock - lists
> the full set of clobbered registers. Please elaborate on the assembly
> wrapper for the function, wouldn't I need to list all the clobbered
> registers there too or am I missing something?
>
The notion there would be that you do push/pop in the assembly wrapper.
>> d) On the other hand, you do *not* need a "memory" clobber.
>
> Right, in this case we have all non-barrier like inlines so no memory
> clobber, according to the comment above alternative() macro.
OK, I'm missing something here.
A few more notions:
a. This is exactly the kind of code where you don't want to put
"volatile" on your asm statement, because it's a pure compute.
b. It is really rather pointless to go through the whole alternatives
work if you are then going to put it inside a function which isn't an
inline ...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists