[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CC46C31D-918D-44AF-8E7C-167B246086A8@zytor.com>
Date: Mon, 16 May 2016 12:22:05 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Peter Zijlstra <peterz@...radead.org>,
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>, x86@...nel.org,
Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: [patch V4 09/31] bitops: Add x86-specific parity functions
On May 16, 2016 10:06:08 AM PDT, Peter Zijlstra <peterz@...radead.org> wrote:
>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 :/
For what it's worth, I have a patchset for cc out just about ready to post. It is in gcc 6.1.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Powered by blists - more mailing lists