[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz4qA2RhjW5KtD+=jnbW-9hoRGgDQ5N6DkQ5LCTkO5idA@mail.gmail.com>
Date: Mon, 13 Nov 2017 15:30:25 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Patrick McLean <chutzpah@...too.org>,
Al Viro <viro@...iv.linux.org.uk>,
Bruce Fields <bfields@...hat.com>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
stable <stable@...r.kernel.org>,
Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: bit tweaks [was: Re: [nfsd4] potentially hardware breaking
regression in 4.14-rc and 4.13.11]
On Mon, Nov 13, 2017 at 2:59 PM, Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
>> Sadly, gcc makes a mess of it and actually generates code that looks
>> like the original C.[...]
>
> Actually, new enough gcc (7.1, I think) does contain a pattern that does
> this, but unfortunately only if one spells it
>
> y |= (x & BIT) ? OTHER_BIT : 0;
Ahh, I should have recognized that, I think that's what we ended up
doing with the VM_READ -> PROT_READ translation in a few places,
exactly because gcc would then recognize it and do the much better
code generation.
> which is half-way to doing it by hand, I suppose.
Yeah, but it is at least acceptable, and the code is still legible C.
The alternatives of doing it _entirely_ by hand tend to be much worse
(ie you end up using a macro from hell that checks which of the two
bits are bigger and shifting in the right direction by using
multiplication or division).
So let's just rewrite that mnt_flags conversion that way, justr to get
gcc to generate the obvious code.
It's a bit sad how gcc didn't pick up on the original code, especially
since it had already done the much more complicated translation of
doing the if-conversion.
Thanks for pointing out the gcc pattern.
Linus
Powered by blists - more mailing lists