On Sat, 11 Aug 2007 02:38:40 +0200, Segher Boessenkool said: > >> That means GCC cannot compile Linux; it already optimises > >> some accesses to scalars to smaller accesses when it knows > >> it is allowed to. Not often though, since it hardly ever > >> helps in the cost model it employs. > > > > Please give an example code snippet + gcc version + arch > > to back this up. > > unsigned char f(unsigned long *p) > { > return *p & 1; > } Not really valid, because it's still able to do one atomic access to compute the result. Now, if you had found an example where it converts a 32-bit atomic access into 2 separate 16-bit accesses that weren't atomic as a whole....
Attachment:
pgpJMeA5UYodK.pgp
Description: PGP signature
- References:
- Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- From: Herbert Xu <[email protected]>
- Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- From: Segher Boessenkool <[email protected]>
- Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- From: Herbert Xu <[email protected]>
- Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- From: Segher Boessenkool <[email protected]>
- Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- Prev by Date: Re: [PATCH 6/24] make atomic_read() behave consistently on frv
- Next by Date: Re: early boot lockup with 2.6.23-rc1
- Previous by thread: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
- Next by thread: [PATCH 2/24] make atomic_read() behave consistently on arm
- Index(es):