[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708181526270.30176@woody.linux-foundation.org>
Date: Sat, 18 Aug 2007 15:41:13 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc: Satyam Sharma <satyam@...radead.org>,
Christoph Lameter <clameter@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Nick Piggin <nickpiggin@...oo.com.au>,
Paul Mackerras <paulus@...ba.org>,
Segher Boessenkool <segher@...nel.crashing.org>,
heiko.carstens@...ibm.com, horms@...ge.net.au,
linux-kernel@...r.kernel.org, rpjday@...dspring.com, ak@...e.de,
netdev@...r.kernel.org, cfriesen@...tel.com,
akpm@...ux-foundation.org, jesper.juhl@...il.com,
linux-arch@...r.kernel.org, zlynx@....org, schwidefsky@...ibm.com,
Chris Snook <csnook@...hat.com>, davem@...emloft.net,
wensong@...ux-vs.org, wjiang@...ilience.com
Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all
architectures
On Sat, 18 Aug 2007, Paul E. McKenney wrote:
>
> One of the gcc guys claimed that he thought that the two-instruction
> sequence would be faster on some x86 machines. I pointed out that
> there might be a concern about code size. I chose not to point out
> that people might also care about the other x86 machines. ;-)
Some (very few) x86 uarchs do tend to prefer "load-store" like code
generation, and doing a "mov [mem],reg + op reg" instead of "op [mem]" can
actually be faster on some of them. Not any that are relevant today,
though.
Also, that has nothing to do with volatile, and should be controlled by
optimization flags (like -mtune). In fact, I thought there was a separate
flag to do that (ie something like "-mload-store"), but I can't find it,
so maybe that's just my fevered brain..
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