[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyssHTdvQ4Gsj9bJB_4X4Ca_JSxmNY0Qv1j=75ixJEajA@mail.gmail.com>
Date: Mon, 15 Jul 2013 11:58:56 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Ramkumar Ramachandra <artagnon@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Eli Friedman <eli.friedman@...il.com>,
Jim Grosbach <grosbach@...le.com>,
Stephen Checkoway <s@...tak.org>, LLVMdev <llvmdev@...uiuc.edu>
Subject: Re: [PATCH] x86/asm: avoid mnemonics without type suffix
On Mon, Jul 15, 2013 at 11:47 AM, H. Peter Anvin <hpa@...or.com> wrote:
>
> To be fair, we *ought to* be able to do something like:
>
> asm volatile(LOCK_PREFIX "bts%z0 %1,%0"
> : BITOP_ADDR(addr) : "Ir" (nr) : "memory");
>
> ... but some older version of gcc are broken and emit "ll" rather than
> "q". Furthermore, since that would actually result in *worse* code
> emitted overall (unnecessary REX prefixes), I'm not exactly happy on the
> idea.
I really think the "worse code" argument is the one that matters.
Specifying the size of the operation is *overspecifying* things,
exactly because the 32-bit encoding is actually the *better* one when
possible.
So it's much better to underspecify and let the assembler pick the
best encoding, than it is to use an explicit size and get worse code.
Which is why I brought up the issue of small constants and short
jumps. I really believe this is exactly the same issue.
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