[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <036b785bc30ad3faa872171d8630542f@kernel.crashing.org>
Date: Sat, 18 Aug 2007 00:29:30 +0200
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Paul Mackerras <paulus@...ba.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,
Nick Piggin <nickpiggin@...oo.com.au>,
linux-arch@...r.kernel.org, jesper.juhl@...il.com,
satyam@...radead.org, zlynx@....org, clameter@....com,
schwidefsky@...ibm.com, Chris Snook <csnook@...hat.com>,
Herbert Xu <herbert.xu@...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
> 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.
It's just a (target-specific, perhaps) missed-optimisation kind
of bug in GCC. Care to file a bug report?
> but is
> (again) something that gcc doesn't dare do, since "i" is volatile.
Just nobody taught it it can do this; perhaps no one wanted to
add optimisations like that, maybe with a reasoning like "people
who hit the go-slow-in-unspecified-ways button should get what
they deserve" ;-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists