Re: [PATCH] [2.5] asm-generic/atomic.h and changes to arm, parisc,

[Luca Barbieri]

--=-f/1FgwUEZgD7gXDm6Z0B
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2002-08-09 at 02:11, Alan Cox wrote:
> On Thu, 2002-08-08 at 23:40, Luca Barbieri wrote:
> > > The compiler can cache the value in a register
> > It shouldn't since it is volatile and the machine has instructions with
> > memory operands.
> 
> I'm curious what part of C99 guarantees that it must generate
> 
> 	add 1 to memory
> 
> not
> 
> 	load memory
> 	add 1
> 	store memory
> 
> It certainly guarantees not to cache it for use next statement, but does
> it actually persuade the compiler to use direct operations on memory ?
> 
> I'm not a C99 language lawyer but genuinely curious
No, I don't claim it is standard behavior (I also don't claim it isn't
and unfortunately the C99 standard is not free so I cannot check it).

I just claim that if the value isn't going to be reused, using the
instruction with memory operands should be faster, because otherwise
there would have been little reason to include it in the instruction set
(except code size optimization, but it seems very unlikely that a CPU
would include CISC instructions just for that).
So a working GCC with optimization enabled should generate it and
especially should always generate it if it generates it in one
compilation (because of volatility).

Of course there is a risk of failure, but it seems small enough to not
worry about it unless there are other good reasons for the compiler to
behave differently.

However OTOH if it fails it would fail subtly so maybe it's better to do
it safely with inline assembly.

--=-f/1FgwUEZgD7gXDm6Z0B
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9UvpAdjkty3ft5+cRAvVpAJ9I7bp58/ScTOg4SsG+w6o52SvIYQCfUHjn
C1bynqRUUt4mBAE4f3OecFw=
=Jnwz
-----END PGP SIGNATURE-----

--=-f/1FgwUEZgD7gXDm6Z0B--