[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160516170608.GV3192@twins.programming.kicks-ass.net>
Date: Mon, 16 May 2016 19:06:08 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Zhaoxiu Zeng <zengzhaoxiu@....com>
Cc: linux-kernel@...r.kernel.org, bp@...e.de,
gnomes@...rguk.ukuu.org.uk, andi@...stfloor.org,
dvyukov@...gle.com, Zhaoxiu Zeng <zhaoxiu.zeng@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: [patch V4 09/31] bitops: Add x86-specific parity functions
On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote:
> On 2016/5/11 17:31, Peter Zijlstra wrote:
> > Please use the GEN_*_RMWcc() stuff to avoid the setpo where possible.
>
> Setpo is better.
> In most cases, we need to store the parity, or compare it with other variables.
>
> For example, in drivers/net/ethernet/broadcom/tg3.c,
>
> static int tg3_test_nvram(struct tg3 *tp)
> {
> ......
> if (parity8(data[i]) == !!parity[i])
> goto out;
> ......
> }
>
> If use GEN_BINARY_RMWcc stuff,
>
> static inline unsigned int __arch_parity8(unsigned int w)
> {
> GEN_BINARY_RMWcc("testb", w, "er", 0xff, "%0", "po");
> }
blergh; GCC does indeed make a mess of that. It looks we'll need the
cc-output stuff for this in order for GCC to generates sane code for
that :/
Powered by blists - more mailing lists