public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luca Barbieri <ldb@ldb.ods.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	Linux-Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [2.5] asm-generic/atomic.h and changes to arm, parisc, mips, m68k, sh, cris to use it
Date: 09 Aug 2002 01:09:52 +0200	[thread overview]
Message-ID: <1028848192.19043.109.camel@ldb> (raw)
In-Reply-To: <1028851871.28883.126.camel@irongate.swansea.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2002-08-08 23:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-08 21:43 [PATCH] [2.5] asm-generic/atomic.h and changes to arm, parisc, mips, m68k, sh, cris to use it Luca Barbieri
2002-08-08 21:58 ` Roman Zippel
2002-08-08 22:11   ` Luca Barbieri
2002-08-08 22:27     ` Roman Zippel
2002-08-08 22:40       ` Luca Barbieri
2002-08-08 23:04         ` Roman Zippel
2002-08-09  0:11         ` Alan Cox
2002-08-08 23:09           ` Luca Barbieri [this message]
2002-08-09  3:52           ` H. Peter Anvin
2002-08-08 23:45     ` Alan Cox
2002-08-12 11:16       ` David Woodhouse
2002-08-12 12:03         ` Luca Barbieri
2002-08-08 23:29 ` Russell King
2002-08-09  0:41   ` [PATCH] [2.5] (v2) " Luca Barbieri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1028848192.19043.109.camel@ldb \
    --to=ldb@ldb.ods.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox