[lkml]   [2007]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures

On Fri, 17 Aug 2007, Paul Mackerras wrote:
> I'm really surprised it's as much as a few K. I tried it on powerpc
> and it only saved 40 bytes (10 instructions) for a G5 config.

One of the things that "volatile" generally screws up is a simple

volatile int i;


which a compiler will generally get horribly, horribly wrong.

In a reasonable world, gcc should just make that be (on x86)

addl $1,i(%rip)

on x86-64, which is indeed what it does without the volatile. But with the
volatile, the compiler gets really nervous, and doesn't dare do it in one
instruction, and thus generates crap like

movl i(%rip), %eax
addl $1, %eax
movl %eax, i(%rip)

instead. For no good reason, except that "volatile" just doesn't have any
good/clear semantics for the compiler, so most compilers will just make it
be "I will not touch this access in any way, shape, or form". Including
even trivially correct instruction optimization/combination.

This is one of the reasons why we should never use "volatile". It
pessimises code generation for no good reason - just because compilers
don't know what the heck it even means!

Now, people don't do "i++" on atomics (you'd use "atomic_inc()" for that),
but people *do* do things like

if (atomic_read(..) <= 1)

On ppc, things like that probably don't much matter. But on x86, it makes
a *huge* difference whether you do

movl i(%rip),%eax
cmpl $1,%eax

or if you can just use the value directly for the operation, like this:

cmpl $1,i(%rip)

which is again a totally obvious and totally safe optimization, but is
(again) something that gcc doesn't dare do, since "i" is volatile.

In other words: "volatile" is a horribly horribly bad way of doing things,
because it generates *worse*code*, for no good reason. You just don't see
it on powerpc, because it's already a load-store architecture, so there is
no "good code" for doing direct-to-memory operations.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-17 05:47    [W:0.266 / U:5.576 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site