[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFycO_d0oO9rw9fXa13NSNc0Am8v+3rV+eSH9YdsCi-2Mg@mail.gmail.com>
Date: Mon, 19 Jan 2015 16:00:23 +1200
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: jsrhbz@...argh.force9.co.uk,
christoph.muellner@...obroma-systems.com,
Guenter Roeck <linux@...ck-us.net>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Anvin <hpa@...or.com>,
Maxime Coquelin <maxime.coquelin@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>, martink@...teo.de,
"Theodore Ts'o" <tytso@....edu>
Cc: "linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions
On Mon, Jan 19, 2015 at 7:54 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The 8- and 16- bit versions are the same as the 32-bit one.
Side note: the 64-bit one is actually different on 32-bit
architectures, not because it would generate a different value, but
because the 64-bit overhead likely kills you. It might be that the
compiler is smart enough that we'd *only* need the 64-bit version, but
for non-constant bit numbers, it's likely hard for gcc to generate
sane single-register versions, and so the 64-bit version is likely
fine.
But I don't see the 8-bit and 16-bit versions generating better code
on any sane architecture.
Linus
--
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